6 ms·
TPDE-LLVM: Faster LLVM -O0 Back-End
- leoh 1y agoI'm glad they mentioned this. When I use Gentoo, though, always compile with -O8 for extreme performance.
- wmf 1y agoI thought everybody moved to Arch. I hear they patched the compiler to go to -O11.
- leoh 1y agoSmart!!
- jeffreygoesto 1y agoBeware, this only works outside of Scotland!
- PoignardAzur 1y agoIt 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.
- webdevver 1y agowhats "the TDPE paper"?
- webdevver 1y agofound it https://docs.tpde.org/ https://docs.tpde.org/ https://arxiv.org/abs/2505.22610 https://arxiv.org/abs/2505.22610
- gbbcf 1y agoCare to enlighten us? Maybe it's just you overestimating the implications
- pertymcpert 1y agoThere'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.
- pjmlp 1y agoMost 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.
- almostgotcaught 1y agoI see you comment here all the time about LLVM and I'm pretty sure you have no idea how LLVM works (technically or organizationally). Yes there's no roadmap but it's flat out wrong that most contributions are from university students because hardly any contributions are from university students. It's actually an issue because we should be more supportive of student contributors! You can literally look at the contributors on GitHub and see that probably the top 100 are professionals contributing as part of their dayjob: https://github.com/llvm/llvm-project/graphs/contributors https://github.com/llvm/llvm-project/graphs/contributors
- pjmlp 1y agoI know enough of what is public information, scattered around LLVM website, public forums, published papers, podcast interviews, LLVM meetings recordings and slides. Thanks for pointing out that is a pile of useless knowledge, maybe I should waste my time reading other stuff more appropriate.
- saagarjha 1y agoNone of that stuff points to LLVM being driven by university students. Most of that content is written directly by people paid to work on the project by their employer.
- pjmlp 1y agoYet most presentations at LLVM Meetings show otherwise, on the list of authors or collaborators. Should we go through an agenda?
- syrusakbary 1y agoThis 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.
- SkiFire13 1y ago> We support a typical subset of LLVM-IR I wonder what such a "typical" subset is. How exotic should something be to not work with it?
- aengelke 1y agoThe documentation has a list of currently unsupported features: https://docs.tpde.org/tpde-llvm-main.html https://docs.tpde.org/tpde-llvm-main.html
- pella 1y agoold discussion: https://news.ycombinator.com/item?id=45084111 https://news.ycombinator.com/item?id=45084111 ( 2 days ago )
- aw1621107 1y agoInterestingly, mpweiher actually submitted first. If you hover over the timestamp for this post you'll see 2025-08-30T06:55:30, while the "old" discussion has a timestamp of 2025-08-31T15:50:35. This particular post got put into the second chance pool [0] and I'm guessing HN's backend decided that now is the time to put it on the front page. [0]: news.ycombinator.com/pool
- tomhow 1y agoVery well spotted. That happens sometimes. Given that this submission is the original for this article, I've moved the comments from https://news.ycombinator.com/item?id=45084111 https://news.ycombinator.com/item?id=45084111 to here, and because there wasn't a huge discussion previously, we'll let this stay on the front page for a while longer.
- twothreeone 1y agoThat rare Comex comment.
- Agingcoder 1y agoTurbo pascal 3 is back !
- baq 1y agogreat news! but linking...
- ahartmetz 1y agoThere are lld and mold for that.
- testdelacc1 1y agoLLVM 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/ 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.
- tialaramex 1y agoIMO the worst problem with LLVM isn't that it's slow, the worst problem is that its IR has poorly defined semantics or its team doesn't actually deliver those semantics and a bug ticket saying "Hey, what gives?" goes in the pile of never-never tickets, making it less useful as a compiler backend even if it was instant. This is the old "correctness versus performance" problem and we already know that "faster but wrong" isn't meaningfully faster it's just wrong, anybody can give a wrong answer immediately and so that's not at all useful.
- randomNumber7 1y agoWhat is the alternative though for a new language though? Transpiring to C or hacking s.th. by using the GCC backend?
- taeric 1y agoDoes TPDE stand for anything? I clicked through quite a ways, and didn't find anything.
- woadwarrior01 1y agoI hope this trickles down to the Swift compiler, sometime soon.
- procrast33 1y agoI 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++. I have no relation to the authors. https://fredrikbk.com/publications/copy-and-patch.pdf https://fredrikbk.com/publications/copy-and-patch.pdf
- aengelke 1y agoThere's a longer paragraph on that topic in Section 8. We also previously built an LLVM back-end using that approach [1]. While that approach leads to even faster compilation, run-time performance is much worse (2.5x slower than LLVM -O0) due to more-or-less impossible register allocation for the snippets. [1]: https://home.cit.tum.de/~engelke/pubs/2403-cc.pdf https://home.cit.tum.de/~engelke/pubs/2403-cc.pdf
- debugnik 1y ago> run-time performance is much worse (2.5x slower than LLVM -O0) How come? The Copy-and-Patch Compilation paper reports: > The generated code runs [...] 14% faster than LLVM -O0. I don't have time right now to compare your approach and benchmark to theirs, but I would have expected comparable performance from what I had read back then.
- t0b1 1y agoThis is in relation to their TPCH benchmark which can be due to a variety of reasons. My guess would be that they can generate stencils for whole operators which can be transformed into more efficient code at stencil generation time while LLVM-O0 gets the operator in LLVM-IR form and can do no such transformation. Though I can't verify this because their benchmark setup seems a bit more involved. When used in a C/C++ compiler the stencils correspond to individual (or a few) LLVM-IR instructions which then leads to bad runtime performance. Also as mentioned, on larger functions register allocation becomes a problem for the Copy-and-Patch approach.
- derefr 1y agoFor a moment I misread this, and thought LLVM had introduced an optimization flag specifically for when your code will be used in backend software. (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?)
- yjftsjthsd-h 1y ago> What, if anything, could such a flag hint the compiler to do? Favor throughput over latency?
- SleepyMyroslav 1y agoJudging 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.
- saagarjha 1y agoDebug builds don’t need to be fast. Or, at least, the benefits you get from faster compilation or better symbols outweigh the downsides.
- aengelke 1y agoIn AoT compilation, unoptimized code is primarily useful for debugging and short compile-test round trips. Your point on C++ is correct, but test workloads are typically small so the cost is often tolerable and TPDE also supports -O1 IR -- nothing precludes using an -O0 back-end with optimized IR, so if performance is relevant for debugging/testing, there's still a measurable compile-time improvement. (Obviously, with -O1 IR, the TPDE-generated code is ~2-3x slower than the code from the LLVM-O1-back-end; but it's still better than using unoptimized IR. It might also be possible to cut down the -O1 pass pipeline to passes that are actually important for performance.) In JIT compilation, a fast baseline is always useful. LLVM is obviously not a great fit (the IR is slow to generate and inspect), but for projects that don't want to roll their own IR and use LLVM for optimized builds anyway, this is an easy way to drastically reduce the startup latency. (There is a JIT case study showing the overhead of LLVM-IR in Section 7/Fig. 10 in the paper.) > And if a project is not large one then build times should not be that much of a problem. I disagree -- I'm always annoyed when my builds take longer than a few seconds, and typically my code changes only involve fewer compilation units than I have CPU cores (even when working on LLVM). There's also this study [1] from Google, which claims that even modest improvements in build times improve productivity. [1]: https://www.computer.org/csdl/magazine/so/2023/04/10176199/1OAJyfknInm https://www.computer.org/csdl/magazine/so/2023/04/10176199/1...
- davikr 1y agoWhat does TPDE stand for?
- CyberDildonics 1y agoThis seems like one of those times where an acronym is used over and over but everyone forgets to define it. What does TPDE stand for? Even on their own pages, their github, their docs, their landing pages, they never define it.