It feels sometimes that compiler backend devs haven't quite registered the implications of the TDPE paper.
As far as I can tell it gets pareto improvements far above LLVM, Cranelift, and any WebAssembly backend out there. You'd expect there to be a rush to either adopt their techniques or at least find arguments why they wouldn't work for generalist use cases, but instead it feels like maintainers of the above project have absolutely no curiosity about it.
There's no free lunch. I don't know where you're getting this "Pareto improvements" thing from because it's a much more constrained codegen framework than LLVM's backend. It supports a much smaller subset, and real world code built by LLVM will use a lot of features like vectors even at -O0 for things like intrinsics. There's a maintenance cost to having a completely separate path for -O0.
Most contributions are driven by university students papers that somehow managed to get merged into LLVM, there is hardly a product manager driving its roadmap, thus naturally not everything gets the same attention span.
This is awseome, I didn't know this was possible and may replace the need of using Cranelift for having fast builds of Wasm bytecode into assembly in Wasmer.
LLVM is the code generation backend used in several languages, like Rust and one of the many compilers for C and C++ (clang). Code generated by these compilers is considered “fast/performant” thanks to LLVM.
The problem with LLVM has always been that it takes a long time to produce code. The post in the link promises a new backend that produces a slower artifact, but does so 10-20x quicker. This is great for debug builds.
This doesn’t mean the compilation as a whole gets quicker. There are 3 steps in compilation
- Front end: transforms source code into an LLVM intermediation representation (IR)
- Backend: this is where LLVM comes in. It accepts LLVM IR and transforms it into machine code
- Linking: a separate program links the artifacts produced by LLVM.
How long does each step take? Really depends on the program we’re trying to compile. This blog post contains timings for one example program (https://blog.rust-lang.org/2023/11/09/parallel-rustc/) to give you an idea. It also depends on whether LLVM is asked to produce a debug build (not performant, but quicker to produce) or a release build (fully optimised, takes longer).
The 10-20x improvement described here doesn’t work yet for clang or rustc, and when it does it will only speed up the backend portion. Nevertheless, this is still an incredible win for compile times because the other two steps can be optimised independently. Great work by everyone involved.
I am curious why the TPDE paper does not mention the Copy-And-Patch paper.
That is a technique that uses LLVM to generate a library of patchable machine code snippets, and during actual compilation those snippets are simply pasted together. In fairness, it is just a proof of concept: they could compile WASM to x64 but not C or C++.
Judging from a lot of points people find -O0 code useful. May I ask if someone from those people tell me how you find it useful? The question is based on following experience: if we have lots of C++ code then all of the std lib and ours abstractions are becoming zero cost only after inlining. Inlining implies at least -O1. Why people even build -O0 for large projects? And if a project is not large one then build times should not be that much of a problem.
19 comments
[ 3.5 ms ] story [ 48.9 ms ] threadAs far as I can tell it gets pareto improvements far above LLVM, Cranelift, and any WebAssembly backend out there. You'd expect there to be a rush to either adopt their techniques or at least find arguments why they wouldn't work for generalist use cases, but instead it feels like maintainers of the above project have absolutely no curiosity about it.
I wonder what such a "typical" subset is. How exotic should something be to not work with it?
The problem with LLVM has always been that it takes a long time to produce code. The post in the link promises a new backend that produces a slower artifact, but does so 10-20x quicker. This is great for debug builds.
This doesn’t mean the compilation as a whole gets quicker. There are 3 steps in compilation
- Front end: transforms source code into an LLVM intermediation representation (IR)
- Backend: this is where LLVM comes in. It accepts LLVM IR and transforms it into machine code
- Linking: a separate program links the artifacts produced by LLVM.
How long does each step take? Really depends on the program we’re trying to compile. This blog post contains timings for one example program (https://blog.rust-lang.org/2023/11/09/parallel-rustc/) to give you an idea. It also depends on whether LLVM is asked to produce a debug build (not performant, but quicker to produce) or a release build (fully optimised, takes longer).
The 10-20x improvement described here doesn’t work yet for clang or rustc, and when it does it will only speed up the backend portion. Nevertheless, this is still an incredible win for compile times because the other two steps can be optimised independently. Great work by everyone involved.
I have no relation to the authors.
https://fredrikbk.com/publications/copy-and-patch.pdf
(Which... that seems like an interesting idea, now that I think of it. What, if anything, could such a flag hint the compiler to do?)
What does TPDE stand for? Even on their own pages, their github, their docs, their landing pages, they never define it.