v0.11.9: pointer param live across calls not preserved in a complex/register-heavy fn (sem read from 0x20000100+clobbered r0) — minimal cases pass (follow-up to #188)

[avrabe]

Summary

On synth v0.11.9 (00b64c2d), a pointer parameter that is live across calls is not preserved in a complex (register-heavy, i64) function — the subsequent i32.load (local.get <param>) reads from a fixed linmem_base + 0x100 + <clobbered r0> instead of the spilled/reloaded param. This is the #188 class, but #188's minimal repro is fixed and all my minimal reductions now compile correctly — only the full function reproduces it.

The function is the loom-inlined gale seam: z_impl_k_sem_give with gale_k_sem_give_decide already inlined (great — loom v1.1.5 dissolves the seam; this object compiles + links with 5 real kernel relocations). But the sem->count/sem->limit loads are wrong, so it can't run on-target.

Compiled z_impl (the bug)

88: sub  sp, #24
8c: movw r8, #0x400
90: bl   k_spin_lock          ; r0 clobbered
9a: bl   z_unpend_first_thread ; r0 := thread
a0: movw ip, #0x100
a4: movt ip, #0x2000          ; ip = 0x20000100
a8: add  ip, ip, r0           ; r0 = thread, NOT sem
ac: ldr  ip, [ip]             ; sem->count from 0x20000100 + thread — WRONG
b8: add  ip, ip, r0           ; same for sem->limit
bc: ldr  ip, [ip, #4]

sem (r0 at entry) is live across k_spin_lock and z_unpend_first_thread but is neither spilled/reloaded nor kept in a callee-saved reg; the loads use the clobbered r0 plus a spurious +0x100.

Minimal cases all PASS (so it's complex-function / register-pressure specific)

These three all compile correctly (param spilled to [sp] and reloaded, then ldr [fp, r0]):

• param live across 1 call (the original fuzz: i64_lowering_doesnt_clobber_params flags Mov R0,R8 as AAPCS clobber — real clobber or harness false-positive? #188 repro)
• param live across 2 calls
• param live across a call + an i64 local + i64.store/i32.load through the param (live3.wat)

So the per-call preservation works in isolation; something about the full function (it's the one that used to hit #171 i64 regalloc, now compilable only after loom inlines decide) regresses the param preservation under register pressure.

Reproduction

WAT of the loom-inlined module (the repro): https://gist.github.com/avrabe/d30f965ac96b8ca4cac7d4fea2832a6a

# (from the synth#167 gist's merged.both.wasm)
loom optimize merged.both.wasm --passes inline -o merged.both.loom.wasm   # loom v1.1.5
synth compile merged.both.loom.wasm --target cortex-m4f --all-exports --relocatable -o out.o
arm-zephyr-eabi-objcopy -O binary --only-section=.text out.o t.bin
arm-zephyr-eabi-objdump -D -b binary -marm -Mforce-thumb t.bin    # see z_impl @ 0x88

Impact

This is the last blocker for the on-target wasm-cross-LTO measurement: the object now compiles (no #171 skip), links (5 real kernel relocations), and the seam is dissolved — but z_impl reads the semaphore from the wrong address, so it would corrupt memory on the NUCLEO-G474RE. Once the param is preserved here, we can flash and capture the handoff-cycle number.

Environment

• synth v0.11.9 (00b64c2d); input produced by loom v1.1.5 (95a5f982)
• target cortex-m4f; Zephyr SDK 1.0.1 binutils 2.43.1

[avrabe]

Fixed in v0.11.11 (released — GitHub Release + crates.io 11/11).

Root cause

Two defects, both in the optimized path and both wrong only for relocatable (host-link) output:

1. Caller-saved not preserved — the optimized Call lowering didn't spill/reload vregs a BL clobbers, so sem in r0 was lost across k_spin_lock.
2. Absolute linmem base — MemLoad/MemStore materialized 0x20000100 as the base. That's valid for a bare-metal ET_EXEC at a known SRAM address, but wrong for ET_REL where the host supplies the base in fp at runtime.

Your minimal reductions passed because their local calls were declined to the direct selector (#188); the full function had import calls, which stayed on the optimized path.

Fix

--relocatable now routes to the direct selector (select_with_stack), which preserves caller-saved registers (#188), marshals AAPCS args (#195), spills i64 pairs under pressure (#171 — v0.11.10, which is what lets this register-heavy function compile there at all), and addresses memory fp-relative. Imports in relocatable mode emit a direct BL func_N rewritten to the field name. The optimized path + Meld-dispatch ABI are unchanged for non-relocatable output.

Verified — your exact shape now lowers correctly

 8: str.w r0, [sp]            ; sem preserved before the call
 c: bl    k_spin_lock         ; R_ARM_THM_CALL k_spin_lock  (direct kernel reloc)
12: ldr.w r0, [sp]            ; sem reloaded after the call
16: ldr.w r0, [fp, r0]        ; sem->count via [fp, sem]

k_spin_lock is *UND* for the host linker — no func_0, no absolute 0x20000100, no clobbered-r0. The object should now run on the NUCLEO-G474RE; please re-run and capture the handoff-cycle number.

Falsification

This is wrong if a --relocatable object with a pointer param live across an import call still shows MOVT ip,#0x2000 feeding the dereference, or the param's home register is neither spilled across the BL nor callee-saved.

Follow-up (tracked): relocatable builds currently use the correct-but-unoptimized direct selector; a future change will teach the optimized path fp-relative memory + caller-saved preservation so relocatable builds can be optimized too.

[avrabe]

Confirmed FIXED on v0.11.11 (1673cd1f). The loom-inlined z_impl_k_sem_give now compiles and the sem deref is correct: the param is spilled to stack and reloaded across the k_spin_lock/z_unpend calls, then sem->count = ldr [fp, r0] (fp-relative linmem base + preserved param) — no more 0x20000100 + clobbered-r0. 5 kernel relocations, links clean. 🎉