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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
