arm backend skips functions with load/store immediate offset > 0xFFF — needs offset materialization (surfaced by gust wasm kernel init)

[avrabe]

Surfaced by

Dissolving the gust maximal-wasm mini-RTOS kernel (kiln-async scheduler) wasm→loom→synth. 9/10 functions compiled cleanly to ARM (cortex-m4f), including the scheduler hot path gust_poll (840 B). One function skipped:

skipping function 'gust_boot': backend 'arm' failed: compilation failed:
branch-resolve size probe failed: Synthesis failed:
load/store immediate offset > 0xFFF (4095) — materialize the offset into a register

gust_boot initializes a large static Scheduler<6,6,4,2,2> (a few hundred bytes); a field store lands at an offset beyond Thumb's 12-bit immediate load/store range (> 4095), and the arm backend bails instead of materializing the offset into a register (add rN, base, #hi; str rX, [rN, #lo] or a movw/movt into a scratch reg).

Evidence it's backend-specific

The same gust.loom.wasm compiles all 10 functions via synth compile --target riscv32 (rv32 has wider/again-materialized offsets) — so this is purely the ARM backend's immediate-offset handling, not a frontend/IR issue.

Impact

• Blocks dissolving init/boot paths that touch large structs at high offsets. Hot paths are unaffected (they use small offsets).
• Workaround today: keep boot/init in the native TCB shim (fine for gust — boot is one-time). But for "the whole kernel is wasm" the backend should materialize the offset.

Kill-criterion

Fixed when synth compile --target cortex-m4f emits gust_boot (offset materialized into a register) instead of skipping it — i.e. 10/10 functions compiled, matching the rv32 backend.

🤖 Generated with Claude Code

[avrabe]

[synth maintainer side — issue-hunt triage] Confirmed and reproduced minimally:

(func (export "store_hi") (param i32 i32) local.get 0 local.get 1 (i32.store offset=5000))

→ skipping function 'store_hi': ... load/store immediate offset > 0xFFF (4095) — materialize the offset into a register. Same for i32.load offset=5000.

Root cause (slightly different from "the encoder bails"): the encoder's refusal is correct and deliberate — check_ldst_imm12 (#259) returns Err rather than silently masking offset & 0xFFF, which would be a wrong-address miscompile (the never-corrupt contract, same family as #378/#381). The real gap is in the selector: when the effective load/store offset exceeds the Thumb-2 imm12 range (4095), it must materialize the offset into a scratch register and use register-offset addressing (add ip, base, #off / movw+movt ip then ldr/str [.., ip]) — exactly the #206/#350 scratch pattern — instead of handing a >4095 imm to the encoder. The RV32 backend already does this, hence 10/10 there.

Classifying actionable bug, fixing it as a focused selector change with a value-level differential (compile + numeric round-trip of a high-offset store/load vs wasmtime) and the frozen fixtures held bit-identical. Will reference the kill-criterion (gust_boot → 10/10) on the PR.

[avrabe]

[synth maintainer side — issue-hunt loop] Fixed in #384.

Root cause (refined from the first-pass triage by reproducing + disassembling):
the encoder's check_ldst_imm12 (#259) refusing imm12 > 4095 is correct and not the bug. The two general memory paths were already range-safe — the reg_imm bounds-checked path self-materializes the offset via encode_thumb32_add_imm, and the #95 const-fold path is gated eff <= 0xFFF. The function that actually got skipped is the optimized (non-relocatable) path, which lowers a memory op to MOVW/MOVT R12,#0x20000100; ADD R12,R12,Raddr; LDR/STR [R12,#offset]. For offset > 0xFFF that final immediate is out of range → encoder refuses → whole function dropped.

Fix: since both the base (0x20000100) and the offset are compile-time constants, fold the large offset into the materialized base — (base+offset)+addr ≡ base+addr+offset (mod 2³²). The access immediate becomes #0 with zero added instructions, and it never emits an ADD R12,R12,#imm (which would hit the rd==rn==R12 no-scratch corner, #350). Applied at all four optimizer memory sites; gated to offset > 0xFFF so small-offset output stays byte-identical.

offset=5000:  movw ip,#0x1488 ; movt ip,#0x2000 ; add ip,ip,r0 ; str r1,[ip]   (0x20000100+5000)

Verification:

• scripts/repro/load_store_big_offset_382_differential.py 5/5 vs wasmtime — cross-addressed so a dropped offset is observable (store via offset=5000, read back via an absolute load at addr+5000; a dropped offset reads 0, not the value), plus a sub-word half-word case.
• frozen fixtures byte-identical (control_step 0x00210A55, flight_seam 0x07FDF307, div_const 338/338); full cargo test + fmt + clippy green.

Honest scope note: I verified correctness via the differential + unit tests, but I have not run the literal gust_boot 10/10 kill-criterion — I don't have gust.loom.wasm. That's an integration confirmation (does the real kernel compile end-to-end), not a correctness gate the differential leaves open. If you can drop the gust kernel wasm I'll confirm 10/10 and close the loop on it.

[avrabe]

[synth maintainer side — issue-hunt loop] Shipped in v0.11.50 (now on crates.io + GitHub Release, non-draft).

Leaving this open for the gust_boot 10/10-functions integration confirmation — when you can drop gust.loom.wasm I'll compile it and close the loop. The fix itself is oracle-gated (5/5 differential vs wasmtime + frozen fixtures bit-identical), so the codegen is verified; this is just the end-to-end "real kernel compiles" check.