[ClangIR] Upstream Progress Report — April 2026

[ClangIR] Upstream Progress Report — April 2026

Follow-up to the ClangIR incubator transition thread. The February post shared initial incubator vs upstream test suite numbers when the incubator was archived. This is an update on upstream progress since then.

All numbers below are from upstream main as of April 10th, 2026 (git hash e2669364745a), compiled at -O2. x86_64 results run natively on Linux; ARM64 results cross-compiled to aarch64-none-linux-android31 and executed on-device (Pixel 10) via adb.

Test Suite Feb (x86_64) April (x86_64) April (ARM64)
SingleSource 86.74% 92.10% 89.0%
MultiSource 55.22% 77.61% 74.2%
SPEC CPU 2017 22.2% 38.9% 27.8%
libcxx (std/) 46.1% 58.5%
Self-hosting 5.9% build

Solid progress across all benchmarks since February. ARM64 outperforms x86_64 on libcxx (58.5% vs 46.1%), likely due to fewer x86-specific NYI blockers. libcxx and self-hosting are measured for the first time, establishing baselines for tracking future progress.

SingleSource

  • x86_64: 1,702 passed, 47 failed, 99 NOEXE (1,848 tests).
  • ARM64: 1,631 passed, 74 failed, 127 NOEXE (1,832 tests).

Build failures are NYI features in CIR codegen (computed goto, exception handling, varargs edge cases). ARM64 execution failures include SIGSEGV crashes in several Shootout-C++ and gcc-c-torture tests.

MultiSource

  • x86_64: 156 passed, 16 failed, 29 NOEXE (201 tests).
  • ARM64: 147 passed, 20 failed, 31 NOEXE (198 tests).

Correctness failures indicate miscompiled code that produces wrong results at runtime.

SPEC CPU 2017

  • x86_64: CINT 4/10, CFP 3/8.
  • ARM64: CINT 2/10, CFP 3/8.

ARM64 compiled 4 CINT + 5 CFP benchmarks, but 525.x264_r, 531.deepsjeng_r (CINT) and 508.namd_r, 538.imagick_r (CFP) crash at runtime with SIGSEGV. 502.gcc_r also fails the baseline and is not CIR-related.

libcxx (std/ subset, 8,695 tests)

The libc++ std/ test suite covers the C++ standard library implementation. Other libcxx subdirs (libcxx-03, extensions, etc) were not included in this run.

Passed Failed Unsupported Pass Rate
x86_64 4,006 4,416 200 46.1%
ARM64 (device) 5,082 3,284 221 58.5%

ARM64 results are from on-device execution (Pixel 10 via adb). The higher pass rate vs x86_64 reflects fewer NYI blockers on ARM64. Of the 3,284 failures, the majority are compilation errors from NYI features. __builtin_verbose_trap alone accounts for 2,373 failures. 79 tests compiled but crashed at runtime (61 SIGABRT, 9 SIGSEGV, 9 watchdog kills).

Self-Hosting

A stage 2 bootstrap was attempted: the CIR-built clang (stage 1) was used to recompile LLVM/clang with -fclangir.

Metric Value
Targets succeeded / attempted 111 / 312 (5.9% of 5,272 total)
Targets failed 201

Not yet ready for self-hosting. The build stalled in the earliest LLVM libraries (Demangle, Support, TableGen) and never reached clang or MLIR sources. Inherited constructor NYI accounts for 67% of failures, hitting using Base::Base; in std::unique_ptr, std::optional, DenseMap, etc.

Top Priority Issues

# Category Impact
1 __builtin_verbose_trap 2,373 libcxx failures
2 Inherited constructor 67% of self-hosting failures, 56 libcxx failures
3 Dynamic-length array / partial array cleanups 61 test-suite files, SPEC 508.namd_r
4 Cleanup branch-through / fixup depth 28 test-suite files, SPEC C++
5 Replace call with mismatched types 23 test-suite files
6 AggExprEmitter: VisitArrayInitLoopExpr 23 test-suite files, SPEC 541.leela_r
7 pushFullExprCleanup in conditional branch 21 test-suite files, SPEC 510.parest_r

ARM64-Specific Issues

# Category Impact
1 ARM method pointer ABI (crash) 70+ SPEC CINT hits, 7 SingleSource — blocks 523.xalancbmk_r, 520.omnetpp_r
2 Runtime SIGSEGV in compiled benchmarks 525.x264_r, 531.deepsjeng_r, 508.namd_r, 538.imagick_r — codegen correctness bugs
3 ARM-style guard variables for static locals NYI 27 hits across SPEC/MultiSource
4 getVTableLinkage: explicit instantiation declaration 92 hits across all suites
5 unsupported type for undef rvalue 64 hits — blocks MultiSource C++ and SPEC CFP
6 emitMaterializeTemporaryExpr: Adjustments 63 hits — blocks SPEC 510.parest_r, 526.blender_r

Questions, corrections, or contributions are welcome.

12 Likes

Since you started this, in response to other things, 2 and 6 on your ‘top priority’ list were completed by me, and number 1 by you, all this week. There might have been a few of the cleanup related ones too in fact, @andykaylor has been hard at work with cleanup fixes.

I don’t know which others have since been implemented, but that should at least take out a significant number of hits. It might be valuable to list which commit-id you used as your benchmark in each for that reason.

That said, Single Source and Multi-Source progress are quite encouraging, quite big jumps in not very much time!

1 Like

Yep! Since it’s a moving target I fixed it to some commit earlier this week, those fixes should be reflected in the next round of updates.

It might be valuable to list which commit-id you used as your benchmark in each for that reason.

Good call, e2669364745a it is, let me update the post.

I think I’ve fixed 3, 4, and 5 from the top priority list and have 7 in progress.

1 Like

Fantastic progress, thank you for the update!

1 Like

Hmm… Looks like between the 3 of us, we killed off the whole ‘top priority’ issues list in about a week (even though at least Andy/I haven’t seen this one). This might have to start being a more frequent progress report, if only to get the priority list repopulated!

1 Like

Y’all rock! Thanks so much for all of the progress.

When something is not yet implemented in CIR, how it is reported?

1 Like

We report ‘not yet implemented’ on the command line, and then fail translation (return non-zero on the command line). We also stop translating after that function as well in many cases (the emitted function, not the compiler-function). We also print source-location information if it is available.

For example, here is one (without source-location info/arrow/etc for some reason) that is in my environment right now:

error: ClangIR code gen Not Yet Implemented: emitNewArrayInitializer: unsupported initializer
1 error generated.
2 Likes