i64-extend chain + Movw R0 clobbers param R0 (fuzz, post-#111)

[avrabe]

Discovery

PR #100's i64_lowering_doesnt_clobber_params fuzz harness, running on a branch with PR #111's I32WrapI64 fix already applied, finds another AAPCS clobber pattern:

AAPCS clobber: ARM instr at wasm line 3 writes param reg R0 before LocalGet(0) at line 5.
Op: Movw { rd: R0, imm16: 0 }

Sequence:
  Push { regs: [R4..R8, LR] }
  I64Const { rdlo: R4, rdhi: R5, value: 0 }
  I64Extend32S { rdlo: R6, rdhi: R7, rnlo: R4 }
  I64Extend32S { rdlo: R8, rdhi: R12, rnlo: R6 }
  Movw { rd: R0, imm16: 0 }            ← bug: pre-assigns R0
  Mov { rd: R0, op2: Reg(R8) }         ← function-return placement
  Pop { regs: [R4..R8, PC] }

Hypothesis

Likely an i32.const 0 (or similar small const) at wasm line 3 emits Movw rd: R0 because the destination allocator returned R0 — same family as #103/#104/#108/#111 but for a different lowering path. The chain of I64Extend32S means r0 is the next 'free' temp candidate from alloc_temp_safe's round-robin and the live-set tracking doesn't include the still-unread param R0.

Bug class

Same family — hardcoded or naively-allocated R0..R3 in instruction emission.

What to fix

Find the wasm op at line 3 of the fuzz-generated program. Likely I32Const lowering or I64Extend32S post-pass. Audit alloc_temp_safe's exclusion list to make sure live AAPCS params (R0..R(num_params-1)) are always excluded for the entire prefix of the function before each param's first LocalGet.

Status

• The fuzz harness is marked continue-on-error in CI as of v0.3.0 — finds bugs at a rate faster than we close in one cycle. Promote back to gating once the bug list stabilises.
• Tracking as v0.3.x patch work.

bug aapcs fuzz-found

[avrabe]

Investigation update (after exploring the no-optimize path):

The crash trace's wasm line 3 sits in the middle of select_with_stack's output, after two I64Extend32S ops. The Movw R0, 0 + Mov R0, R8 pair right before the Pop epilogue looks like the i64→i32 function-return placement: the function returns an i32, but the wasm stack's top is an i64 (after the two extends). The epilogue zeros R0 then overwrites with the low half (R8) — but the Movw R0, 0 is a redundant dead store that the harness still flags.

The lowering is correct in the sense that the param register is overwritten by the epilogue's return-value placement, which is the function's last act. The harness's invariant ("any R{p} write before LocalGet(p)") doesn't account for ARM ops emitted by the function epilogue that legitimately write R0..R1 for the return value.

Candidate fixes (pick one, both narrow):

• (a) Optimizer side: drop the redundant Movw R0, 0 when followed immediately by a Mov R0, _. Peephole pattern, ~10 LoC.
• (b) Harness side: carve out ARM ops whose source wasm op is the function-final End (or any epilogue-emitted op). Mirrors the LocalSet(p)/LocalTee(p) carve-out we already have.

(b) is the cheaper, more honest fix — the underlying codegen isn't actually wrong, just inefficient by one dead store. Keeping this open for v0.3.x.