LLVM developers are debating whether Clang should compile ClangIR into every build. Erich Keane posted an RFC titled "Enable ClangIR Build By Default" on the LLVM Discourse forum on September 6, 2026. It had drawn 34 replies by the time Phoronix reported it the same day.
The proposal is narrower than the headline suggests. Building it in is not the same as using it.
What is actually being proposed
ClangIR is a new intermediate representation for Clang. An intermediate representation is the form a compiler holds your code in between parsing it and emitting machine instructions.
Clang already has one, LLVM IR. ClangIR sits higher up, closer to the source language, and is built on MLIR. Sitting higher means it can keep information that LLVM IR throws away, such as which C++ construct a piece of code came from.
The code is already upstream. It is simply not part of the default build configuration, so most people compiling Clang from source do not get it.
The RFC would change that one thing. Code generation would still go through the existing path unless you pass -fclangir explicitly. Nobody gets ClangIR by accident.
The objections
Three concerns dominate the thread, and none is about whether ClangIR is good work.
| Concern | The problem |
|---|---|
| Build time | Some estimates put build times more than doubling |
| Platform gaps | Microsoft and Windows targets are not supported |
| CI cost | Every test machine pays the longer build, on every run |
The build-time figure is the one doing the damage. Adding MLIR as a default Clang dependency pulls in a large body of code that everyone compiling Clang would then compile too, including people who will never pass the flag.
That cost is not evenly shared. A distribution maintainer building Clang once absorbs it easily. A contributor rebuilding locally, or a CI fleet rebuilding on every pull request, absorbs it repeatedly.
Why anyone wants it on
The case for building it in is adoption. A feature nobody compiles is a feature nobody tests. Keeping ClangIR out of the default build means bugs surface only for the small group who opt in, and only after the code has already landed.
Turning it on by default makes it a normal part of the tree. Breakage shows up in ordinary CI rather than in a specialised bot, which is how a project stops an experimental component from quietly rotting.
Nothing has been decided. It is an RFC with an active thread, and the discussion is about cost rather than direction.
What this means for developers
If you build Clang from source, watch this thread rather than the outcome. Your build times are the thing being traded away, and the estimates in the thread are estimates. Measuring your own build with MLIR included is a better input to your planning than a number from a forum post.
If you run CI that compiles LLVM, cost this now. A doubling applied to every pull request is a budget line, not an inconvenience, and it arrives on whatever release first carries the change.
If you work on Windows toolchains, the platform gap is your cue to speak up. The RFC names the absence of Microsoft target support as a blocker, and RFC threads are where that gets weighted. Open-source projects have been formalising exactly this kind of decision lately, from GNOME drafting an RFC process to Debian voting on AI-assisted contributions.
And if you just use Clang from a package manager, this changes nothing yet. You would get a slightly larger compiler binary and an extra flag you can ignore.
This article was first published on Tech AI Wire.
Also available in
Deutsch · 日本語 · Français · Español · Português
Related on Tech AI Wire
- GNOME drafts an RFC process for big technical decisions
- Debian votes to allow AI-assisted contributions, with conditions
Sources
- LLVM Developers Discuss Enabling ClangIR Build By Default - Phoronix
- RFC: Enable ClangIR Build By Default - LLVM Discourse
Top comments (0)