LLVM -O3 Pipeline Study Finds 84.8% of Speedup Comes in Final 15% of Passes
New research cracks open the black box of LLVM optimization with 84,750 measurements.
A comprehensive empirical study by Federico Bruzzone and Walter Cazzola has systematically decomposed the LLVM -O3 optimization pipeline into 113 cumulative per-pass prefixes. Across 84,750 measurements covering execution time, compile time, binary size, hardware counters, and RAPL energy on 30 compute-bound PolyBench/C kernels with rigorous noise mitigation, the results reveal several counterintuitive properties. The pipeline is non-monotone: 6.6–9.7% of individual pass transitions actually regress performance. Furthermore, gains are heavily back-loaded — the median non-regressing kernel requires 84.8% of the total pipeline passes just to achieve 80% of its speedup. A small Pareto-dominant core of passes drives most gains, while the full -O3 configuration is Pareto-dominated on the (binary size, speedup) frontier for 29 out of 30 kernels.
These findings have direct implications for compiler engineers and autotuning systems. The study shows that IR instruction count is an unreliable predictor of runtime, and that runtime-targeted passes are de facto energy-targeted, delivering 30–60% energy savings. The search-free idealized-additive upper bound on losses due to phase interference was measured at 46.35%, meaning almost half the potential performance can be lost from suboptimal pass ordering. This work enables more informed pass pruning, cost-model calibration, and autotuning strategies. For developers relying on LLVM for C/C++, Rust, or MLIR-based stacks, it suggests that -O3 is far from optimal and that significant compile-time reductions are possible without sacrificing performance.
- Pipeline is non-monotone: 6.6-9.7% of pass transitions cause performance regression.
- Median kernel needs 84.8% of pipeline passes to achieve 80% of its speedup.
- Final -O3 configuration is Pareto-dominated on (binary size, speedup) for 29 out of 30 kernels.
Why It Matters
Compiler engineers can now prune the -O3 pipeline, saving compile time without sacrificing performance.