Case Study
LLVM DSE Pass
A compiler optimization pass for LLVM 18 that eliminates memory writes the standard -O2 pass leaves behind. Three independent strategies, each validated with FileCheck tests, achieving around 4% more dead stores eliminated and 1.2% smaller binaries on real benchmarks.
3 independent out-of-tree LLVM optimization strategies
Caught silent exception-path correctness bug in MemorySSA
~4% dead stores eliminated beyond -O2 on PolyBench/C
What
Custom LLVM 18 optimization pass implemented as an out-of-tree plugin on the new pass manager.
Eliminates redundant memory writes that -O2 leaves behind using three strategies: write-only alloca removal, MemorySSA-based dominated store elimination, and pre-lifetime.end store pruning.
Validated with 14 lit/FileCheck tests.
Benchmarked against 30 PolyBench/C kernels: ~4% additional dead stores eliminated beyond -O2, ~1.2% binary size reduction, under 3% compile overhead.
Why
Stores that were clearly dead still survived standard optimization. The interesting problem was removing more of them without breaking correctness.
Who
Compiler engineers evaluating optimization safety, systems developers studying LLVM IR, and performance teams measuring codegen impact.
When / Where
Matters most in compiler optimization work where small IR changes can affect correctness across many programs.
Constraints
Had to plug into LLVM 18's new pass manager without touching any in-tree source files.
The analysis has to be sound. If two pointers might alias, or a store sits before a potential exception, it can't be eliminated.
Needed a repeatable way to measure whether the pass actually helped, not just assume it did.
What
Custom LLVM 18 optimization pass implemented as an out-of-tree plugin on the new pass manager.
Eliminates redundant memory writes that -O2 leaves behind using three strategies: write-only alloca removal, MemorySSA-based dominated store elimination, and pre-lifetime.end store pruning.
Validated with 14 lit/FileCheck tests.
Benchmarked against 30 PolyBench/C kernels: ~4% additional dead stores eliminated beyond -O2, ~1.2% binary size reduction, under 3% compile overhead.
Why
Stores that were clearly dead still survived standard optimization. The interesting problem was removing more of them without breaking correctness.
Who
Compiler engineers evaluating optimization safety, systems developers studying LLVM IR, and performance teams measuring codegen impact.
When / Where
Matters most in compiler optimization work where small IR changes can affect correctness across many programs.
Constraints
Had to plug into LLVM 18's new pass manager without touching any in-tree source files.
The analysis has to be sound. If two pointers might alias, or a store sits before a potential exception, it can't be eliminated.
Needed a repeatable way to measure whether the pass actually helped, not just assume it did.