RFC would enable ClangIR by default, at steep build cost

ClangIR maintainers have proposed building ClangIR into Clang by default, arguing the upstreamed IR is mature enough to justify broader testing and outside contribution. The change would make MLIR a required Clang dependency and fold CIR tests into ordinary check-clang and continuous integration runs. Default code generation would stay as it is today: CIR would still be selected only with -fclangir. A CMake switch would remain for anyone who wants CIR off.

Erich Keane, posting with other ClangIR maintainers, said builds with -fclangir already clear more than 98 percent of the SingleSource suite and all of MultiSource, with a full stage2 self-host still limited mainly by a small set of ABI issues. He estimated the extra dependency would grow full compiler build time by roughly one third, and pledged that the CIR team would help fix the uncommon breakages CIR tests have caused. The same post and follow-ups pointed to early CIR optimization work, including standard-library algorithm recognition that can keep calls such as std::find intact long enough to prove a rewrite to a C library routine such as memchr before lowering to LLVM IR. Andy Kaylor argued that turning CIR on by default would draw more of that kind of C and C++-level analysis.

Cost figures drew sharp pushback. Local measurements shared against the RFC showed Clang configure wall time up about 51 percent, build wall time and CPU time more than doubling (around +130 percent and +137 percent), peak RSS more than tripling, and build-tree size roughly doubling. The same commenter voted no, saying many people build Clang only as a C/C++ front end to LLVM IR and get little from MLIR, and suggested a separate top-level project or driver rather than loading the main Clang binary and every CI job. Others asked for work on MLIR build overhead itself, including more precompiled headers, before any mandatory dependency, noting MLIR is already among the most expensive parts of an LLVM build on modest hardware.

Premerge maintainers said they could absorb the CI side and did not expect the added work to stand out much against existing volume. The RFC would also start putting ClangIR changes into release notes. It is still an open proposal.