Yes. Memory consumption of such an approach will be more than the traditional approach.  But we can alleviate it in 2, 3 ways. If we start from the bottom and call newCompile() for a source-file, it might depend on a header-file which might depend on another header-file, and so on till the standard header files. So, a lot of compiler-states will need to be kept. But if start from the top, it can only depend on standard headers, hence fewer compiler-states will need to be preserved. However, as we move down, we will have more and more ifc files. As we compile we can free ifc file resources if there is no other compilation-unit left that can depend on that ifc. Linking can be moved to the end and before that, we can clear all the ifc.  I checked aggregated .obj file size in llvm cmake-build-debug directory. It is around 5GB. I think the maximum size of the ifc files needs to be kept around at any time will be around that as well. 

Because of this, I feel on a machine with 32GB RAM and 12 threads, 2 llvm configurations can be compiled simultaneously without any problem. 12GB of ifc files + compiler states will exist in memory. The remaining 18GB will be available for 12 compiler threads. And before linking, all of these will be written back to the disk. If this takes more memory, the user will always have the option to fall back to the conventional solution.

Best,

Hassan Sajjad