TL;DR
The lead maintainer of LLVM published a run‑through of recurring project problems and partial fixes, citing areas such as code review capacity, API churn, build and CI pain, sparse end‑to‑end testing, backend divergence and slow compilation. A few longstanding IR issues have been addressed (opaque pointers) or are in progress (ptradd), but systemic process and testing gaps remain.
What happened
In a detailed post, LLVM’s lead maintainer cataloged a set of structural and technical problems he sees in the project. He notes three IR design issues previously highlighted: one resolved (opaque pointers), one largely addressed (removal of constant expressions), and one actively being migrated (ptradd). Beyond those items, he expands the critique to cover review capacity shortfalls, high churn in the C++ API and IR, lengthy builds and painful debug builds, and a brittle CI landscape driven by over 200 post‑commit buildbots. The writeup also flags a shortage of end‑to‑end executable tests (the llvm‑test‑suite sits separately and is limited), backend divergence where fixes target single architectures, and ongoing slow compilation times—particularly at -O0. Suggested mitigations include Rust‑style reviewer assignment, precompiled headers, default dylib builds and more serious attention to flaky tests, though concrete adoption timelines are not specified.
Why it matters
- Insufficient reviewer capacity can delay contributions and allow inadequately reviewed code to land.
- Frequent API and IR changes impose maintenance costs on downstream projects and tight integrations.
- Long build and CI cycles slow developer feedback and make development on low‑spec hardware difficult.
- Lack of broad end‑to‑end tests and backend divergence increases the risk of regressions across targets.
Key facts
- The author identifies as the lead maintainer of the LLVM project.
- One historical IR issue (opaque pointers) has been fully migrated; constant expression removal is mostly done; ptradd migration is underway.
- LLVM’s C++ tree exceeds 2.5 million lines of code; the broader monorepo is roughly 9 million lines.
- The project has thousands of contributors with a relatively flat contribution distribution, but not enough qualified reviewers.
- Review responsibility currently rests with PR authors, and finding appropriate reviewers is challenging for newcomers.
- There are over 200 post‑commit buildbots that exercise many configurations; typical workdays see more than 150 commits.
- Pre‑merge testing improved PR CI hygiene, but long and flaky post‑commit buildbots still generate noisy failure signals.
- End‑to‑end executable tests are not part of LLVM’s primary test suite; a separate llvm‑test‑suite exists but has limited coverage.
- Compilation time has improved in places but remains a problem, especially at -O0; an alternative backend (TPDE) demonstrates potential large gains.
- There is no single, official LLVM performance‑tracking infrastructure; many organizations track performance downstream independently.
What to watch next
- Progress on the ptradd migration that the author says is 'well on the way' (confirmed in the source).
- Adoption of precompiled headers and a default dylib build to reduce build time and debug linking costs (suggested in the source; outcomes not confirmed in the source).
- Efforts to reduce flaky tests and stabilize post‑commit buildbots and CI signal; the author calls for taking flakiness more seriously (intent stated in the source; specific plans not confirmed in the source).
Quick glossary
- LLVM IR: An intermediate representation used by LLVM for program analysis and transformation between frontends and backends.
- CI (Continuous Integration): Automated systems that build and test code changes to catch regressions and integration failures early.
- Dylib build: A build configuration that links code into shared dynamic libraries, which can reduce link times and disk usage compared with static monoliths.
- Precompiled header: A compiler feature that stores the result of parsing frequently included headers to speed up subsequent compilations.
Reader FAQ
Who wrote the analysis?
The post was written from the perspective of LLVM’s lead maintainer (confirmed in the source).
Which IR issues have been fixed or are in progress?
Opaque pointers migration is reported as fixed; constant expression removal is mostly finished; ptradd migration is in progress (confirmed in the source).
Does LLVM have comprehensive end‑to‑end executable tests?
No — the primary LLVM test suite lacks executable end‑to‑end coverage; a separate llvm‑test‑suite exists but has limited coverage (confirmed in the source).
Is there an official LLVM performance tracking system?
Not confirmed in the source.
« Back to article overview. LLVM: The bad parts 11. January 2026 A few years ago, I wrote a blog post on design issues in LLVM IR. Since then, one…
Sources
- LLVM: The bad parts
- Do you assign GitHub issues?
- The mess that is handling structure arguments and returns …
- What's the bad side about LLVM?
Related posts
- When ‘Computers’ Were People: A Short History of Human Calculators
- Understanding Message Queues: Post Offices, Warehouses and Microservices
- Date Is Out, Temporal Is In — Why JavaScript’s Date Needs Replacing