arm regalloc: i64 consecutive-pair spill / coalescing (root of #168)

[avrabe]

Follow-up to #168 (mitigated by skip-and-continue in PR #169).

The ARM register allocator hard-fails with "no consecutive pair of free registers for i64" on i64-heavy functions (e.g. compiler_builtins::float::div). PR #169 makes --all-exports skip such a function instead of aborting the module, but the function still does not compile.

Real fixes (from the #168 suggestions), in increasing order of effort:

1. Spill one operand of the i64 pair to a stack slot when no consecutive pair is free (graceful degradation).
2. Register-pair coalescing / pre-coloring pass for i64 values so consecutive pairs are reserved up front.

This is what unblocks actually compiling (not just skipping) f64 division and other i64-heavy compiler_builtins.

[avrabe]

Escalation — with #178 fixed (7b4f4b51), this is now the sole synth blocker for the cross-language-LTO-via-wasm on-target measurement.

The #178 fix (decline-to-optimize linmem-op functions) routes our hot-path primitive z_impl_k_sem_give through the unoptimized, register-hungry path, where it now hits this exactly:

warning: skipping function 'z_impl_k_sem_give': backend 'arm' failed: ... 
register exhaustion: no consecutive pair of free registers for i64 — function too complex for current register allocator

z_impl_k_sem_give is i64-heavy by design — it unpacks the u64 AAPCS-packed decision returned by gale_k_sem_give_decide(count, limit, has_waiter) (action byte + new_count). The value-only decide itself compiles fine; it's the shim's z_impl (i64 unpack + pointer deref to sem) that can't get a consecutive pair.

So the i64 consecutive-pair spill (not just graceful-skip from #168) is what's needed to compile the real function. With #171 done, merged.both.o should carry a working z_impl_k_sem_give and we can finally flash it on the NUCLEO-G474RE for the wasm-cross-LTO cycle number. Repro module is the merged.both.wasm from the #167 gist (z_impl + decide + 5 kernel imports); synth compile merged.both.wasm --target cortex-m4f --all-exports --relocatable reproduces the skip.

[avrabe]

Recurring on v0.11.8 (09c264bf) — the #188 fix (preserve caller-saved regs across calls, ) is correct on the minimal case, but its added spilling pushes z_impl_k_sem_give back over this allocator limit:

warning: skipping function 'z_impl_k_sem_give': backend 'arm' failed: ...
register exhaustion: no consecutive pair of free registers for i64 — function too complex

It compiled briefly on v0.11.6 (before #188), but now that params live across the k_spin_lock/z_unpend_first_thread calls must be spilled+reloaded, the i64 consecutive-pair allocator runs out again. z_impl is the stress case: i64 (u64-packed decision unpack) + several calls (so caller-saved spills) + a pointer param. A real consecutive-pair spill (this issue) that can spill an i64 pair to the stack when no register pair is free is what's needed for it to compile under the #188 preservation. Repro: synth compile merged.both.wasm --target cortex-m4f --all-exports --relocatable (WAT in the #167 gist) → skips z_impl.

This is now the sole synth blocker for the on-target wasm-cross-LTO measurement (#188 made the codegen correct; #171 keeps z_impl from compiling).

[avrabe]

Status + complete design (after 3 agent attempts)

The regression is understood and acknowledged: #188's caller-saved preservation added register pressure (it parks the call return in a callee-saved reg, e.g. mov r4, r0, which reserves R4 — half of the (R4,R5) i64 pair), tipping i64-heavy + multi-call functions like z_impl_k_sem_give over the consecutive-pair limit. So it regressed from compiling (v0.11.6) to skipped (v0.11.8). The proper fix is the i64-pair spill below.

Three background-agent attempts have failed identically — each gets ~90% through the required 200-site operand-stack refactor, then crashes/times-out leaving the i64-critical selector non-compiling (and one left tangled handlers). The refactor cannot reach a compiling checkpoint until the whole pass is done, so an interrupted run corrupts the highest-stakes code. Conclusion: this needs a single focused, direct implementation pass (not a background agent), with incremental verification against the acceptance test. It is the next dedicated-session item.

The validated design (ready to execute)

1. select_with_stack's operand stack Vec<Reg> → Vec<StackVal> where enum StackVal { Reg(Reg), Spilled { lo_slot: i32 } }. An i64 value is its lo reg; hi = i64_pair_hi(lo). ~200 sites (51 push → StackVal::Reg, 85 pop → reload-if-spilled helper, 65 index/iter → handle Spilled).
2. stack_live_regs: only Reg entries reserve r + i64_pair_hi(r); Spilled reserve nothing.
3. alloc_consecutive_pair on exhaustion: spill_deepest_reg — find the deepest Reg entry, reserve an 8-byte frame slot (extend LocalLayout like spill_base), emit STR lo,[sp,slot]; STR hi,[sp,slot+4], set the entry to Spilled{slot}, retry. (Conservative: spilling an i32 entry's pair stores a harmless garbage hi.)
4. Pop of a Spilled entry: alloc a fresh consecutive pair, LDR lo,[sp,slot]; LDR hi,[sp,slot+4], return lo.

Acceptance

test_171_i64_exhaustion_is_clean_error_not_panic (6 I64Const + 5 I64Add) must change from asserting Err to asserting Ok (compiles via spill). #188 + #195 tests must still pass.

Until then the #168 skip-and-continue mitigation holds (affected functions are dropped, never miscompiled).

[avrabe]

Confirmed FIXED on v0.11.11 (1673cd1f, via #198 'spill i64 register pairs + call results under pressure'). z_impl_k_sem_give (i64 + 6-calls + ptr param) now compiles with no register-exhaustion skip. Thank you!