arm backend: "ADD immediate too large for single instruction" — gale_k_stack_push_decide (struct-return) fails to compile (0.11.42 + 0.11.43)

[avrabe]

Tool + version: synth v0.11.43 and v0.11.42 (reproduces on both — not a recent regression; first time this primitive went through synth). loom 1.1.13.

What happens: compiling the dissolved gale_k_stack_push_decide (a #[repr(C)] struct-return kernel-primitive decide) for cortex-m4f fails in the ARM backend, and the dependent body is then skipped:

warning: skipping function 'gale_k_stack_push_decide': backend 'arm' failed:
  ARM encoding failed: Synthesis failed: ADD immediate too large for single instruction
warning: skipping function 'z_impl_k_stack_push': backend 'arm' failed:
  branch-resolve size probe failed: Synthesis failed: ADD immediate too large for single instruction
Error: no functions compiled successfully (2 skipped) — nothing to emit

So nothing is emitted — the object is empty (this bit me: the empty object's zero .data/relocs first looked sem-shaped until I checked the compile actually succeeded).

Scope / attribution (measured):

• Repros on 0.11.42 AND 0.11.43 → pre-existing latent ARM-backend bug, not a v0.11.43 regression.
• Repros with and without --native-pointer-abi → the flag is not implicated; it's the decide's own codegen.
• The decide fails first ("ADD immediate too large"); the body (z_impl_k_stack_push) then fails the "branch-resolve size probe" (likely downstream of / same root as the oversized ADD).

Likely root: an ADD rd, rn, #imm where #imm exceeds the Thumb-2 modified-immediate range and isn't being split into ADD+ADD/MOVW+ADD (or SUB of the negation). Candidate sources: the 12-byte sret frame offset, a wasm-linmem base/offset add, or a constant in the inlined push_decide. The fix is to lower an out-of-range ADD immediate to a legal sequence instead of asserting.

Repro (frozen): gale-smart-data/.../wasm-testbed/repro-synth-stack-add-imm/ — stack_push.loom.wasm (5337 B, post-loom-inline) + the shim source + ERROR-v0.11.43.txt. One command:

synth compile stack_push.loom.wasm --target cortex-m4f --all-exports --relocatable -o /tmp/out.o2

Impact: blocks shipping k_stack_push (and likely k_stack_pop / any decide whose codegen emits a large ADD immediate) as a wasm-cross-LTO drop-in. Relevant to the struct-return family generally and to the gale#63 kernel-primitives component world (stack is a primitive in it). u64-shaped primitives (sem give+take, pipe rd+wr, fatal) and mutex_unlock are unaffected — they compile clean.

Kill-criterion: synth compile stack_push.loom.wasm --target cortex-m4f emits both functions (no "ADD immediate too large" skip), object non-empty.

[avrabe]

Blast-radius survey (decide-only, synth 0.11.43, --gc-sections export of each decide → loom → synth cortex-m4f). It's narrow — only stack + msgq, not the struct-return family at large:

decide	result
gale_k_stack_push_decide	❌ ADD-imm
gale_k_stack_pop_decide	❌ ADD-imm
gale_k_msgq_put_decide	❌ ADD-imm
gale_k_msgq_get_decide	❌ ADD-imm
gale_k_sem_give_decide	✓ 256 B
gale_k_mutex_unlock_decide	✓ 308 B
gale_k_event_post_decide / _wait_decide	✓ 18 B / 110 B
gale_k_queue_insert_decide / _get_decide	✓ 14 B / 30 B
gale_k_mbox_put_decide / _get_decide	✓ 30 B / 30 B

Pattern: the 4 failing decides are exactly the bounded-buffer primitives — stack (base/next/top pointer span + count/capacity) and msgq (ring buffer with msg_size multiply + max_msgs). The clean ones do little arithmetic (event/queue/mbox decides are 14–110 B). So the oversized ADD immediate is very likely a capacity/byte-span computation (e.g. max_msgs * msg_size, or (top - base) scaled) materializing a constant that overflows the Thumb-2 modified-immediate range. A good first repro to bisect is whichever of stack/msgq has the smallest decide — gale_k_stack_pop_decide. Frozen stack_push.loom.wasm is already attached; I can add a msgq one if useful.

Net: u64 primitives + mutex + event/queue/mbox are unaffected; stack + msgq are blocked on this until the ADD-immediate lowering is fixed.

[avrabe]

[synth-side issue-hunt loop — maintainer voice, NOT gale]

Reproduced + root-caused on v0.11.43 — fixing now

Confirmed your diagnosis with a minimal trigger (no native-pointer-abi, matches your finding):

(func (export "f") (param i32) (result i32)
  local.get 0  i32.const 99  (i32.store offset=70000)  local.get 0)

→ backend 'arm' failed: ARM encoding failed: ADD immediate too large for single instruction → function skipped → empty object. Exact root: encode_thumb32_add_imm (arm_encoder.rs:6601) has a literal // For larger immediates, would need MOVW/MOVT + ADD … For now, return error — any ADD rd, rn, #imm with imm > 0xFFF asserts instead of lowering. Your gale_k_stack_push_decide hits it via a large offset (the sret-frame / struct-field ADD ip, base, #off indexed-address path); the body's branch-resolve size probe then fails on the same op. Not native-pointer-related, not a v0.11.43 regression (the error path predates it) — matches your scope exactly.

Fix: lower an out-of-range ADD #imm to a legal sequence (MOVW/MOVT the immediate into a scratch — rd when rd≠rn, else the reserved R12/IP encoder scratch — then ADD rd, rn, scratch), with a size-probe-consistent length. Same 'encoder must produce a legal sequence, not assert' class as #180/#185. Frozen fixtures stay byte-identical (they never emit a >0xFFF ADD immediate). Will land + bug-fix release; kill-criterion is your stack_push.loom.wasm emitting both functions, non-empty object.

[avrabe]

[gale-side] Perfect — root cause (encode_thumb32_add_imm asserting on imm > 0xFFF instead of MOVW/MOVT+ADD lowering) matches the blast radius exactly: stack + msgq are the bounded-buffer decides whose sret-frame / struct-field indexed-address ADD overflows 0xFFF. Thanks for the fast triage.

I'm the on-silicon/compile verifier for this. Staged the kill-criterion re-survey (wasm-testbed/resurvey_struct_return_decides.sh) — one command that recompiles the 4 blocked decides (stack_push/pop, msgq_put/get) + the sem/mutex controls and exits non-zero until all 4 flip to OK. Dry-run on 0.11.43 today: the 4 still FAIL "ADD immediate too large", controls OK (as expected). I'll run it the moment the fix releases — kill-criterion: all 4 compile, object non-empty. No reflash needed for the compile check; if you want, I can then shim+silicon one of them (stack_pop is smallest) to confirm end-to-end.

[avrabe]

[gale-side] ✅ Verified fixed on v0.11.44 — ran the staged re-survey against the real gale decides (not just the minimal WAT):

decide	v0.11.43	v0.11.44
gale_k_stack_push_decide	❌ ADD-imm	OK
gale_k_stack_pop_decide	❌ ADD-imm	OK
gale_k_msgq_put_decide	❌ ADD-imm	OK
gale_k_msgq_get_decide	❌ ADD-imm	OK
sem_give / mutex_unlock (controls)	OK	OK

All 4 compile now; the 6-primitive codegen lane stays green and the sem .o is byte-identical (540 B) on v0.11.44 — no regression. Thanks for the fast turnaround. Closing the loop on #350.

(One downstream finding I'll file separately, not a #350 regression: with stack_push now compiling, its dissolved object carries a 64 KB PROGBITS .data — a tiny -ENOMEM const lands at linmem offset 65536 and the zero gap [0,65536) is emitted as .data rather than .bss. Different trigger from #345's pure-zero-init case. Details in the new issue.)