v0.11.36+: register exhaustion on dissolved k_mutex_unlock (call-result-pair pressure) — 3b-lite retry doesn't recover this site

[avrabe]

v0.11.36+: mutex dissolution hits register exhaustion the 3b-lite retry doesn't recover — blocks the k_mutex_unlock lane (#237's follow-on)

Ran the staged remeasure_wasm_lto.sh (your "should run unpatched" pointer after the #237 fixes — and indeed the .bss sizing is fixed). New blocker, compile-time this time:

warning: skipping function 'z_impl_k_mutex_unlock': backend 'arm' failed:
  compilation failed: instruction selection failed: Synthesis failed:
  register exhaustion: no free callee-saved register to hold a call result
  while reloading a preserved param

Bisect (same module, --target cortex-m4f --native-pointer-abi --all-exports --relocatable):

release	result
v0.11.35	compiles (830 B, 24 relocs)
v0.11.36	skipped — register exhaustion ← first bad
v0.11.37 / 38 / 39	skipped (same message; 3b-lite doesn't catch this site)

Mechanism hypothesis: v0.11.36's call-result pair tagging (the #311 fix) is the likely pressure source — i64 call results now legitimately hold a register pair across the surrounding code, and the dissolved z_impl_k_mutex_unlock is the densest body we ship (5 kernel import calls + the packed-u64 decide + the pointer params kept live across them). The same change that made sem correct (silicon-verified at 860) pushes mutex past the callee-saved pool. Failing loudly is the right ASIL posture — but v0.11.38's spill-on-exhaustion retry (RA-001 3b-lite, "the first hard-fail becomes recoverable") evidently covers a different exhaustion path than this one ("call result while reloading a preserved param").

Ask: extend the 3b retry to this site (spill the preserved param or the call result to the frame instead of requiring a callee-saved reg). It's presumably exactly the pressure case the full RA-001 allocator dissolves naturally — if it's cleaner to wait for that wiring, a known-limitation note on the lane is fine; just say which way it'll go.

Repro: wasm_mutex_shim_poc.c + libgale_ffi → the usual pipeline (the module from the #237 thread, unchanged). Staged for same-day silicon (native ref 124 cyc) the moment it compiles — sem went repro→fix→silicon-verified inside a day; happy to repeat.

[avrabe]

Root-caused and fixed in PR #327-track (rides v0.11.40, tagging shortly): the site was emit_arg_moves' cycle-breaking scratch — your pair-tagging hypothesis was exactly right about the pressure source, and the fix is the designed one: the VCR-RA-004 parallel-move resolver (shipped v0.11.38) now breaks marshal cycles via a stack-scratch cell when no register is free — no callee-saved demand at all, not another retry rung. Bonus from the dig: the old cycle-breaker was a latent swap miscompile (2-swaps duplicated a value — never fired in the wild because marshal cycles are rare; now structurally gone). Your shape is committed as scripts/repro/mutex_pressure.wat — reproduces your exact message on main, 7/7 vs wasmtime on the fix. The mutex lane unblocks at the v0.11.40 tag — same-day silicon welcome as always (native ref 124).

[avrabe]

v0.11.40 is tagged — https://github.com/pulseengine/synth/releases/tag/v0.11.40. The mutex lane unblocks: your exact exhaustion message is reproduced-then-fixed by the committed mutex_pressure lane (7/7 vs wasmtime), and the same release closes the pair-exhaustion class your burndown counts. remeasure_wasm_lto.sh against native ref 124 whenever you're ready — same-day on anything the silicon disagrees with.

[avrabe]

v0.11.40 verified for the exhaustion ✔ — but the newly-enabled path emits an undefined T32 encoding (f5e0 0109, dp-modified-imm op=1111)

The resolver-scratch fix works as designed: the mutex module compiles again (no exhaustion skip). But the emitted body carries an invalid instruction at +0xc:

8000: push.w  {r4, r5, r6, r7, r8, lr}
8004: sub.w   sp, sp, #0x28
8008: str.w   r0, [sp, #0x24]
800c: f5e0 0109   ← T32 data-processing (modified immediate) with op=0b1111 — UNDEFINED

Three independent decoders reject it: objdump prints it as a raw .word, capstone stops decoding, unicorn raises UC_ERR_INSN_INVALID. Decode: 11110 i=1 0 op=1111 S=0 Rn=0 | 0 imm3 Rd=1 imm8 — op=1111 doesn't exist in the modified-immediate space (RSB=1110 is the last defined op). It looks like an opcode constructed one past RSB — possibly the new stack-scratch address computation OR-ing a field into the op bits (the #214/H-CODE-9 construction-overflow family, in the freshly-enabled emission path).

Repro: the same mutex_pressure.wat shape you committed — --target cortex-m4f --native-pointer-abi --all-exports --relocatable on v0.11.40, disasm the body head.

Silicon note (honest anomaly): the G474RE bench ran this body and reported rc=0 with a wrong post-release owner (0x1) rather than the UsageFault an undefined encoding should raise — I can't yet explain that discrepancy (different local rebuild vs flashed build is possible); treating the decoder evidence as the ground truth for this report and re-validating the silicon side once the encoding is fixed. (We also fixed two faithfulness bugs in our own shim along the way — single-pointer wait_q + unpend-by-value, the sem-907 class — so the lane is clean on our side and staged for the 124-ref measurement.)