main red: js_array_alloc in the packed_f64_fast hot-loop epilogue fails native-region-proof (blocks releases)

[proggeramlug]

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.

[proggeramlug]

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:

for.packed_f64_fast.body.54.i.epil:
  %r232.i.epil = load double, ptr %r231.i.epil, align 8
  %r233.i.epil = fadd double %r203.135.i.epil, %r232.i.epil
  ...
  br i1 %epil.iter.cmp.not, label %"...exit", label %for.packed_f64_fast.body.54.i.epil

The js_array_alloc is in the next block, building console.log's argument array.

Mechanism. extract_blocks matched 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):

parser	blocks	hot loops	hot-loop js calls
before	510	29	{"for.packed_f64_fast.body.54.i.epil": ["js_array_alloc"]}
after	512	29	{}

Hot-loop count is unchanged, so the fix does not hide loops. Sweeping every workload in that artifact, packed_f64_loop_versioning is the only verdict that moves — h1_buffer_alias_negative and image_convolution are unchanged — so no masked failure is exposed.

No codegen change is needed; #9337's output is correct.