LLVM: The Bad Parts
4 months ago
- #Compiler
- #Optimization
- #LLVM
- LLVM faces challenges with review capacity, leading to slow PR reviews and potential bad changes being merged.
- The project experiences high churn in its C++ API and IR, balancing innovation with stability costs.
- Build times are significant due to LLVM's size and C++ compilation overhead, with some mitigation strategies in place.
- CI stability issues persist with flaky tests and buildbots, diluting the signal for real failures.
- End-to-end testing is lacking, particularly for executable tests and comprehensive operation coverage.
- Backend divergence is a problem, with fixes often being target-specific rather than generic.
- Compilation time remains an issue, especially for -O0, despite recent improvements.
- Performance tracking is insufficient, with no official infrastructure for monitoring runtime performance.
- IR design issues include problems with undef values, unsoundness, and specification incompleteness.
- Constraint encoding in LLVM is fragmented across different mechanisms, each with tradeoffs.
- Floating-point semantics outside strict IEEE 754 compliance are problematic.
- Partial migrations, like the new pass manager and GlobalISel, have been ongoing for years without full adoption.
- ABI and calling convention handling is messy, with unclear contracts between frontend and backend.
- Builtins and libcalls management is complicated by multiple sources of truth and lack of customization.
- The context/module dichotomy in LLVM creates friction, especially around data layout access.
- LICM increases register pressure without adequate backend sinking to mitigate it.