Making the Clang AST Leaner and Faster(cppalliance.org)
cppalliance.org
Making the Clang AST Leaner and Faster
https://cppalliance.org/mizvekov,/clang/2025/10/20/Making-Clang-AST-Leaner-Faster.html
9 comments
Optimizations that require changes to data flow are some of the trickiest to get through. Even when the benefits are great, it will feel like a loss to some to take something away to make everything faster. Is this really worth it?
That's awesome improvement!
Great stuff!
But, I’m afraid it will actually lead to even more heavily templated C++ in a rebound effect!
But, I’m afraid it will actually lead to even more heavily templated C++ in a rebound effect!
Impressive work! Also waiting for fine-grained caching:
https://discourse.llvm.org/t/rfc-add-an-llvm-cas-library-and...
https://discourse.llvm.org/t/rfc-add-an-llvm-cas-library-and...
That is dated Feb 2022. Do you know if anything came of it?
Quite a few patches have landed. A couple features using this have already shipped in Apple’s downstream clang.
>Modern C++ codebases — from browsers to GPU frameworks — rely heavily on templates, and that often means massive abstract syntax trees.
Symptom of a symptom. Templates are abhorrent abominations. However, there’s no way to do generics without them. It just becomes a hairball mess at compile time… kudos for alleviating some of the pain in waiting.
Symptom of a symptom. Templates are abhorrent abominations. However, there’s no way to do generics without them. It just becomes a hairball mess at compile time… kudos for alleviating some of the pain in waiting.
The C++ implementation, sure. But there is plenty of other implementation space without giving up like Java.
With a trait-first implementation that mostly defers monomorphization and prefers "static if" over C++-style specialized implementations, the only hard choice is whether to optimize codegen for size or speed.
Trying to retrofit this onto standard C++ is ... not actually as difficult as you might think. The real problem is the implementation of builtins that rely heavily on "this really must be a constant during X phase of compilation".
With a trait-first implementation that mostly defers monomorphization and prefers "static if" over C++-style specialized implementations, the only hard choice is whether to optimize codegen for size or speed.
Trying to retrofit this onto standard C++ is ... not actually as difficult as you might think. The real problem is the implementation of builtins that rely heavily on "this really must be a constant during X phase of compilation".
Im not sure what the originating symptom is in your comment. I read your comment as saying:
‘requiring generics’ -> C++ Templates -> massive ASTs
Is that correct? If so I’d then wonder if the applies from strictly within the bounds of C++ the language. Is there an alternate meaning? I think there are quite a few viable ways to present what are usually called ‘generics’ at several levels of abstraction and in several programming paradigms, so any reading outside of C++ seems strange.
‘requiring generics’ -> C++ Templates -> massive ASTs
Is that correct? If so I’d then wonder if the applies from strictly within the bounds of C++ the language. Is there an alternate meaning? I think there are quite a few viable ways to present what are usually called ‘generics’ at several levels of abstraction and in several programming paradigms, so any reading outside of C++ seems strange.