This discussion introduces TPDE-LLVM, an open-source alternative back-end to LLVM's -O0 (unoptimized) compilation, boasting 10-20 times faster compilation speeds. Developed by aengelke, TPDE-LLVM aims to significantly reduce build times for debug versions while maintaining comparable runtime performance and a moderately larger code size (10-30% for -O0 IR). It currently targets x86-64 and AArch64 and employs a streamlined three-pass compilation approach. The discussion also touches upon the broader context of compiler performance, including bottlenecks in front-ends, potential improvements to LLVM-IR design for faster compilation, and debates around LLVM's IR semantics versus raw speed. Community feedback highlights the excitement for faster debug builds, while also acknowledging TPDE-LLVM's current limitations in IR feature support and the inherent trade-offs between speed, code size, and semantic correctness in compiler design.
Summarizing TPDE-LLVM: A Leap in Unoptimized Code Generation Speed
Introduction to TPDE-LLVM (Forum Post - Start):
Key Takeaway: TPDE-LLVM is an open-source, fast LLVM baseline back-end that offers a 10-20x speedup over the standard LLVM -O0 back-end for compile-time.
Details: It provides similar runtime performance and results in 10-30% larger code size for -O0 IR. The project targets x86-64 and AArch64 architectures and supports a typical subset of LLVM-IR.
Performance Benchmarks (Forum Post - Data Table):
Details: On SPEC CPU 2017 (x86-64), TPDE-LLVM achieves a geomean compile-time speedup of 13.34x for -O0 IR and 17.58x for -O1 IR, relative to LLVM 19 -O0. Code size is 1.27x larger for -O0 IR but 0.97x (slightly smaller) for -O1 IR. AArch64 results are comparable, with slightly higher speedups.
Operational Mechanism (Forum Post - "How Does It Work?"):
Details: TPDE-LLVM operates through three main passes: an IR cleanup/preparation pass, an analysis pass (loop + liveness), and a combined codegen pass that performs lowering, register allocation, and machine code encoding.
Current State and Limitations (Forum Post - "Features & Future Plans"):
Details: It's designed to support typical Clang O0/O1 IR, with Flang code often working. Rust code can encounter issues with "illegal" (not natively supported) vector types, which are not yet fully implemented. Other unsupported features include some floating-point operations and multi-word integers beyond i128.
Future Development Plans (Forum Post - "Features & Future Plans"):
Details: Plans include implementing DWARF support (a prototype exists), improving register allocation beyond "spill everything," and potentially expanding to non-ELF platforms, non-small-PIC code models, and other targets based on community motivation.
Integration and Usage (Forum Post - "How to use TPDE-LLVM?"):
Details: TPDE-LLVM is available as a library (e.g., for JIT compilation with ORC JIT), an llc-like tool, and can be integrated into Clang (requiring a patch, as plugins cannot provide custom back-ends).
Suggestions for LLVM-IR Improvements (Forum Post - "Which changes to LLVM-IR could allow even faster compilation?"):
Key Takeaway: Achieving a 10x speedup in LLVM would require deeper changes to its IR.
Details: Suggestions include eliminating ConstantExpr inside functions, avoiding arbitrarily-sized struct/array values, using intrinsics for thread-local globals instead of direct access, and limiting arbitrary bit-width arithmetic (e.g., i260).
Key Takeaway: The 10-20x speedup is a significant win for debug builds, where faster compilation is prioritized over optimal runtime performance or minimal code size.
Details: This improvement primarily speeds up the back-end stage of compilation. For tools like Clang with TPDE-LLVM, the front-end becomes the dominant bottleneck (>98% of compile time).
Key Takeaway: A critical concern raised is the "poorly defined semantics" of LLVM's IR, which can lead to "faster but wrong" results, undermining the value of speed improvements.
Hacker News Discussion - "No Free Lunch" (HN - pertymcpert):
Details: While impressive, TPDE-LLVM is described as a "constrained codegen framework" with a smaller supported subset of features compared to LLVM, implying inherent trade-offs and a maintenance cost for a separate -O0 path.
Hacker News Discussion - Type Legalization (HN - mshockwave, aengelke):
Details: TPDE-LLVM does not perform full type legalization; it lowers types to "basic types" and handles ad-hoc legalization during instruction compilation. For illegal vector types, the current plan is to scalarize them, potentially leading to deliberate incompatibility with LLVM’s undocumented ABI.