[clang] [llvm] Added partial support for compiling C++20 modules and header-units without scanning. (PR #147682)

Fri Dec 12 09:56:12 PST 2025

HassanSajjad-302 wrote:

I have successfully implemented shared memory files for Windows. Currently, testing it for Linux. Now, the speed-up for boost debug is a little more to 2.5x from previously 2.3x. Shared memory files means that this also consumes 10 - 20% less memory.

> Please understand the concern for maintainability. It really scares me to see a patch with 5k lines of change for a brand-new feature—especially since human resources for Clang/C++ core developers are extremely limited. We have to be careful.

I fully understand it. Just want to say that there is a separation of concern and a clear front-end and backend. If the integration-test `IPC2978Test` in `clang/unittests/IPC2978/IPC2978Test.cpp` works, then you can just glance over the backend API.

>Back to the patch itself: the most concerning/confusing point, in my experience, is that the bottleneck of a build process generally comes from the compiler itself, rather than the build system or the communication between the compiler and the build system. In complex real-world projects I’ve seen, most compilation time is spent on template instantiations and middle/back-end optimizations.

>Amdahl’s Law tells us that the overall speedup from optimizing a subsystem is limited by the proportion of that subsystem within the whole system. My concern is: is it worth introducing such a large feature to optimize the cold part of the entire process—especially when the new model hasn’t been widely proven yet?

I would like to mention a [comment](https://www.reddit.com/r/cpp/comments/1jb8acg/comment/mhvvfva/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button) by a bigcheeesegs. This is a very insightful comment imo. They argue that the risk of using header-units for build-perf increase is worth it. They also mention that there is no easy way to move to modules with contemporary build-systems and with their build model. Easiest solution is a build-server. HMake is precisely this. This build-server model has been discussed [often](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1602r0.pdf) for a long time. However, none except HMake could  actually implement it.

>The proof consists of two parts:

>We need to see the proportion of the cost of the build system itself and the cost of communication between the build system and compilers within the entire build process for large/complex projects.
Then, we need to evaluate how good the new model actually is.

>Aside from the new model, regarding HMake—I truly appreciate what you’ve done. But to be honest, HMake needs more users and successful case studies to demonstrate its value, so that more tools will support the new model it introduces. Build systems aren’t hard in principle, but they are very complex in practice. Due to this complexity, migrating to a new build system isn’t easy. Nobody I know is eager to write build scripts. So I feel it’s hard for HMake to attract new users today. Then I am sorry that creates a chicken-and-egg problem if HMake really depends on this patch. But as I said, we have to be careful.

>If HMake is really, really good—and the changes in Clang are truly necessary—I do think you could pursue it via a plugin or a fork first. That would be simpler

I promoted my software to the Boost community. Unfortunately, they think that the cost is not worth it. I plan to re-request them with more libraries completed and similarly I plan to reach-out to other projects as-well. I also request you to promote HMake.

I believe that LLVM can be compiled >10x faster with my software. And the cost of switching is very minimal as well. I welcome anyone for a review. It is extensively tested. I can do a video-call desktop sharing presentation explaining all details, answering any questions. Reviewers will find my software 10/10 on all accounts.

I believe that with the collaboration, the transition can be completed in less than 2 months. If the compilation fails, there will always be the option to fallback to conventional model or to point out the culprit header-unit and compile it as a header-file instead until the bug gets fixed. LLVM uses C++17. That means that the chances of breakage with hu are little. Boost-Example that I did is with C++26. Also, LLVM plans to move to C++20. In that case the perf-benefit further increases.

I can myself compile clang + llvm (x86 backend only without tests or other supporting features docs etc)  in 3 weeks provided the current build maintainers are willing to get in touch. Like, why the build might be failing. Or explaining some current build-system and code-generation steps. Then they can do a detailed review after 3 weeks for further adoption. On my system it takes around 8mints. It would take < 1mint.

HMake is very extensible and A tier in code-generations, making test reports etc. Having full-context and vertical integration (between the traditionally separate build-system generator and the build-system) and the ability to modify the central DAG will allow for further optimizations to fully saturate the cores. I can't overstress how important that could be. If you ever thought about build-system supporting some custom features, HMake will probably be able to.

I am ok if this pull-request is not merged. I can point potential HMake users to your comment and that you are willing to merge if they are willing to become HMake users.

I would like to request the lead maintainer @AaronBallman for a comment.

Please see [link](https://discourse.llvm.org/t/rfc-hmake-for-llvm/88997/4). I posted some screenshots and build log there.

Again, CMake is the de-facto blockade as far as the adoption of modules goes. Boost effort is not going anywhere e.g.

https://github.com/llvm/llvm-project/pull/147682