Repository navigation
main red: js_array_alloc in the packed_f64_fast hot-loop epilogue fails native-region-proof (blocks releases) #9494
Description
Symptom
compiler-output-regression fails, so main-gate is red on main and
full-suite-gate cannot pass — this blocks every release cut.
The native-region-proof suite reports 1 of 11 scenarios failing:
workload: packed_f64_loop_versioning
status: fail
errors:
hot_loops_no_runtime_calls: hot loop runtime calls:
{"for.packed_f64_fast.body.54.i.epil": ["js_array_alloc"]};
allowed=["js_array_numeric_value…"]
A js_array_alloc is being emitted inside the packed_f64_fast hot-loop
epilogue, which this proof exists to forbid — that loop is meant to be
allocation-free.
Not a stale expectation
The gate asserts a performance-correctness invariant about emitted code, and
the emitted code now violates it. Unlike the other release blockers I have hit
today (stale test expectations trailing deliberate improvements), there is no
sense in which the new behaviour is more correct — an allocation in a hot loop
epilogue is the thing the invariant is about.
Likely origin
c78cf37acf — "codegen: affine window hoist + accumulator array axis — matmul
2x faster (#9337)" — is packed-loop versioning work, and the failing block is
the packed_f64_fast epilogue specifically. The .epil suffix suggests the
allocation is landing in the loop's epilogue rather than the main body, so a
hoist that is correct for the body may not be covering the epilogue.
I have deliberately not guessed at a fix: this is in-flight optimisation
work and the right change depends on where the allocation is intended to live.
Evidence
Nightly full tier on main: run 33575873453, 2026-09-02, sha 82f49699cb.
Still red on main as of f1e9c370ad. The other 10 scenarios in the suite pass.
Reproduce
python3 -m scripts.compiler_output_harness.cli --suite native-region-proof
# or scope to the one workload:
# --workload packed_f64_loop_versioning
The structural report is written to
target/compiler-output-regression/native-region-proof/packed_f64_loop_versioning/structural-report.json.
Why it matters beyond CI
hot_loops_no_runtime_calls is the invariant behind the packed-loop fast path.
If an allocation is genuinely in that epilogue, the workload is doing heap work
per iteration-tail that the optimisation is supposed to have removed — a
performance regression, not only a red gate.
Activity
proggeramlug commentedon Sep 2, 2026
Diagnosis: this is a harness false positive, not a codegen regression. Fix in #9510.
The reported block contains no calls at all — it is a clean scalar epilogue:
The
js_array_allocis in the next block, buildingconsole.log's argument array.Mechanism.
extract_blocksmatched labels with^([A-Za-z0-9_.$-]+):(?:\s|$). LLVM quotes identifiers outside its bare-name set, and #9337's specialization puts a$in function names, so the following label is emitted as"perry_fn_…$spec_i32.exit":. That line starts with", so it never matched — no new block began and the quoted block's body was appended to the previous label.Note the failure direction: mis-attribution can only ever move calls into the preceding block, so this produces false positives, never false negatives, for the block that absorbs them.
Verified against the exact IR CI analyzed (run
33598905771, not a local rebuild):{"for.packed_f64_fast.body.54.i.epil": ["js_array_alloc"]}{}Hot-loop count is unchanged, so the fix does not hide loops. Sweeping every workload in that artifact,
packed_f64_loop_versioningis the only verdict that moves —h1_buffer_alias_negativeandimage_convolutionare unchanged — so no masked failure is exposed.No codegen change is needed; #9337's output is correct.
fix(harness): a quoted LLVM label must start a new basic block (#9494) (