[clang] [llvm] Enable ClangIR Build By Default (PR #221291)

[Fangrui Song via cfe-commits]

MaskRay wrote:

Ideally, this PR would declare `CLANG_ENABLE_CIR` with a default of `OFF`, together with the dylib fix and the docs, and a separate one-line PR would flip it to `ON` once there is consensus.
I don't see consensus beyond the Clang area team's acceptance in [/100](https://discourse.llvm.org/t/rfc-enable-clangir-build-by-default/91730/100), and I'm challenging that acceptance because it leaves out the build cost, the support tier, and what users get.
(/NNN below are posts in the [RFC](https://discourse.llvm.org/t/rfc-enable-clangir-build-by-default/91730).)

**The cost is not what the acceptance assumed.** /100 accepted "roughly 1.2x" for building clang. Every independent measurement taken after the September build-cost work is higher: +30% CPU and +71% wall for an X86 dylib build (/87), +50% wall on the compile-time tracker, which now turns CIR off (/103). /1 itself estimated "roughly 1/3", and this PR's release note says "measureable and significant". Since /100, the only build-cost change to land is my #231068 (a PCH for clangCIR), which leaves CIR at about +30% of clang's build CPU by my estimate. Nobody has proposed an option to drop OpenACC/OpenMP from CIR, the largest remaining cut. With CIR on, the dylib build, the configuration most distributors ship, produces a clang that fails on `int main() {}` with "Broken module found". It was reported in /22, /64 and /87, and the fix only appeared in this PR on Oct 14.

**Flipping the default changes CIR's support tier without saying so.** CIR was upstreamed as peripheral tier, with Bruno's assurance that the breakage burden would stay with CIR developers. /1 says that once CIR is built by default, "committing a patch that breaks CIR would require 'fixing' ClangIR tests". That is the core-tier obligation. /100 doesn't mention the tier and says CI wasn't discussed, and the [CI RFC](https://discourse.llvm.org/t/rfc-add-cir-testing-to-clang-and-mlir-ci/92452) shows no consensus on exactly this question. If CIR is to become core, that should be an explicit decision, not a side effect of a CMake default.

**Users of a default build get little for it.** `-fclangir` has no debug info, modules, or sanitizers and little non-x86 support, and a `-fclangir`-built clang fails 2,074 of its own check-clang tests ([September report](https://discourse.llvm.org/t/clangir-progress-report-september-2026/91947)). Chrome, Android, the compile-time tracker, and possibly Red Hat are already opting out (/30, /42, /93, /103). Everyone else would pay about 30% more build CPU so that release binaries carry an experimental flag.

**It would also hurt ClangIR.** Many end users and packagers will first hear of ClangIR as the thing that made their clang build slower and that their distribution turned off. If they also learn it was enabled by default over this much objection and at this cost, that becomes ClangIR's reputation, more than its real progress on correctness. A default flipped by consensus, after the build cost is cut, would serve the project better.

What I'd like before the flip:

- Add an option to build CIR without OpenACC and OpenMP.
- Get an explicit decision on CIR's tier (core or peripheral), together with the CI RFC.
- Add a dylib build to CIR's own testing.

https://github.com/llvm/llvm-project/pull/221291