Re:Making the Clang AST Leaner and Faster
by reactordev on Wednesday November 12, 2025 @05:56PM
(#45908077)
>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.
Re:Making the Clang AST Leaner and Faster
by o11c on Wednesday November 12, 2025 @07:59PM
(#45909121)
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".
Re:Making the Clang AST Leaner and Faster
by throwaway17_17 on Wednesday November 12, 2025 @09:16PM
(#45909661)
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.
Re:Making the Clang AST Leaner and Faster
by hinkley on Thursday November 13, 2025 @12:00AM
(#45910868)
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?
But, I’m afraid it will actually lead to even more heavily templated C++ in a rebound effect!
https://discourse.llvm.org/t/rfc-add-an-llvm-cas-library-and...
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.
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".
‘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.