Synth is unable to compile a recent falcon-cascade binary

[cpetig]

A meld'ed falcon-cascade.wasm is rejected by synth compile in.wasm --target cortex-m7 --relocatable --all-exports --embedder-data-init --embedder-global-init -o out.wasm
with

warning: skipping function 'pulseengine:falcon-cascade/controller@0.10.0#step': backend 'arm' failed: compilation failed: instruction selection failed: Synthesis failed: #1069: spill-slot pool exhausted while frame-homing a VFP local — more frame-resident float locals than the pool holds; the backend retries with a pool sized from the function's local count and this surfaces only if that also fails

A wasm-optimized version gives more errors

warning: skipping function 'pulseengine:falcon-cascade/controller@0.10.0#step': backend 'arm' failed: compilation failed: instruction selection failed: Synthesis failed: #1069: spill-slot pool exhausted while frame-homing a VFP local — more frame-resident float locals than the pool holds; the backend retries with a pool sized from the function's local count and this surfaces only if that also fails
warning: skipping function 'func_4': backend 'arm' failed: compilation failed: instruction selection failed: Synthesis failed: GI-FPU-002: an integer operation peeked an f32 (VFP) stack value — invalid wasm or an unlowered float op reached the integer path

errors.zip

[avrabe]

[synth coordinator] Reproduced on v0.68.0 (tagged today, bd81bc8c), with your exact command line and both attached modules. Thank you for attaching them — that is what made this measurable rather than guessed.

What I measure

module	functions skipped	mechanism
fused.wasm	1 of 21 — pulseengine:falcon-cascade/controller@0.10.0#step	#1069 spill-slot pool exhausted while frame-homing a VFP local
opt.wasm	7 of 17 — step, plus func_4, func_5, func_8, func_10, func_11, func_12	1× #1069 on step, 6× GI-FPU-002 on the helpers

Two notes on the numbers, since re-deriving them changed them:

1. Your excerpt shows two errors on the optimized module; the full run skips seven functions, six of them GI-FPU-002. I mention it because the count is what tells us GI-FPU-002 is a class here and not a one-off.
2. The optimized module fails more than the unoptimized one. The wasm-opt output shape is what surfaces GI-FPU-002, so the two failures are not the same defect wearing two hats — they need separate reproductions.

Both mechanisms are loud declines, not silent wrong code: the affected functions are left out of the object rather than miscompiled. That is the intended failure direction, but it does not help you — the export you need is the one that declines.

Disposition

This is a must-priority item in v0.69, whose planning starts now, ahead of the rest of the candidate pool: an exported entry point of a real downstream module not compiling outranks internal cleanup. The two will be worked as separate reproductions:

• GI-FPU-002: three named cascade entry points are the entire remaining gap to a complete falcon M7 image (attitude#tick, ekf#estimate, position#tick) — everything else in the chain now works #1069 — the frame-homing spill-slot pool is exhausted even after the retry with a pool sized from the function's local count. The fixture generator scripts/gen_vfp_local_1069.py already builds pressure cases; your step is a real one with a shape we do not have.
• GI-FPU-002 — an integer operation reached an f32 stack value, which means a float op was not lowered somewhere upstream on the optimized shape. This one carries a correctness obligation, so it gets an execution differential, not just "it compiles now".

Two questions so the fix targets what you actually need:

1. Is cortex-m7 the target you need, or would cortex-m7dp / cortex-m4f also be acceptable? The VFP register pressure differs across them, and it changes which fix matters first.
2. Is the module built from a toolchain you can rebuild? If the step function's source shape can be reduced, a smaller repro makes the pressure case exact — but if not, the attached module is enough to work from.

I will keep the measurements on this issue as the lane proceeds. Refs #1069

[avrabe]

[synth coordinator] Progress, with the measurements, since the two mechanisms turned out not to be what the error said.

What was actually stopping step

Not the spill-slot pool. synth's recovery ladder tries four rungs, and it was reporting the second rung's error while a later one failed differently. Instrumenting each rung on your fused.wasm:

rung	outcome
vfp-spill	VFP register file exhausted (S0..S15 all live)
vfp-frame-locals	spill-slot pool exhausted (#1069)
vfp-frame-locals + pool grown to its 120-slot cap	VFP spill slot offset 1248 exceeds the VSTR/VLDR [sp,#imm] range (1020)
vfp-wide-file (the callee-saved half of the register file)	spill-slot pool exhausted (#1069)

The wall is the addressing range. VSTR/VLDR encode their offset as imm8*4, so they reach 1020 bytes from the stack pointer; integer LDR/STR reach 4095. synth reserves the VFP call-spill area after every other frame field — deliberately, so that adding it never moved an existing function's offsets — and once the pool grows for a float-dense function, that area lands out of range. Your step declares 39 f32 locals, all assigned, across 61 distinct assignment targets.

So the message you were shown named a symptom two rungs earlier than the cause. That is fixed independently: the decline now reports every rung it tried and what each one hit.

Where it stands

Reserving that area where those instructions can reach it — only under the rung that fires for functions which already failed everything else, so nothing that compiles today changes — gets step past the range wall. It then hits a different and more serious problem, which synth's register-allocation validator catches and refuses to emit:

VCR-RA-003: SpillSlotAliased { slot: 184, first_store: 11113, overwriting_store: 11150, stale_reload: 11159 }

Two values sharing one frame slot, with a reload that would read the wrong one. I measured that this is not caused by the layout change — the violation is identical with and without it — so it is a pre-existing defect in that rung, previously unreachable behind the range wall. Filed as #1321.

I want to be plain about what this means for you: step still does not compile. What changed is that the remaining blocker is now a specific, located defect rather than a misleading message, and that the validator is refusing to hand you an object that would have been silently wrong.

opt.wasm is unchanged so far — still 7 of 17 functions skipped, six on GI-FPU-002. That half carries a correctness obligation and will be fixed against an execution differential, not against "it compiles now".

Still open, from my last comment

Neither question is answered yet, and both change what gets fixed first:

1. Is cortex-m7 the target you need, or would cortex-m7dp / cortex-m4f also do?
2. Can the module be rebuilt from source, so step could be reduced to a smaller pressure case?

No rush — I will keep going on what is measurable meanwhile.

Refs #1321, #1069, #719

[cpetig]

Thank you for the hint, any of these will do for the FMU on the X500V2RT. I guess m7dp should be the most easy to achieve, I will give it a try tomorrow.

[cpetig]

Answers to both open questions, with measurements.

1. Target: cortex-m7 vs cortex-m7dp vs cortex-m4f

The target does not matter. I ran all three on v0.68.0 (synth 0.68.0, meld 0.56.2, wasm-tools 1.254.0), against both the raw published component and a meld-fused core module derived from it:

target	result
cortex-m7	VCR-RA-003: SpillSlotAliased { slot: 184, first_store: 11113, overwriting_store: 11150, stale_reload: 11159 }
cortex-m7dp	VCR-RA-003: SpillSlotAliased { slot: 184, first_store: 11103, overwriting_store: 11140, stale_reload: 11149 }
cortex-m4f	VCR-RA-003: SpillSlotAliased { slot: 184, first_store: 11113, overwriting_store: 11150, stale_reload: 11159 }

One export skipped in every case, always pulseengine:falcon-cascade/controller@0.10.0#step, and the other exports compile.

So my earlier "m7dp should be the easiest, I will try tomorrow" was wrong and I am withdrawing it — please do not spend any scheduling on the target axis on my account.

The slot index is 184 on all three. The two integer offsets shift by 10 between m7dp and the other two, which is the frame-layout difference you would expect, but the aliased slot is identical. If #1321's allocation is target-parameterised anywhere, that constancy may narrow where to look — the conflict appears to be decided before target-specific VFP pressure enters.

2. Can the module be rebuilt from source?

Yes. falcon-cascade is built in our tree from five leaf components that are then composed, so step is reducible and I can produce smaller pressure cases on request. Tell me what shape is most useful — fewer f32 locals at the same nesting, or the same 39 locals with the call graph flattened — and I will build it. I would rather generate the one you want than guess and send you three.

A contrast case that may be more useful than a reduction

The same five stages, fused as separate leaves instead of composed into one step, compile cleanly on v0.68.0:

meld fuse --profile safety --memory shared --address-rebase \
  falcon-{ekf,position,attitude,rate,mixer}-v1.58.wasm
synth compile --target cortex-m7 --relocatable --all-exports \
  --embedder-data-init --embedder-global-init

.text 26622 B, 0 functions skipped, 5 declared pages

00000004 g F .text 000004e0 pulseengine:falcon-cascade/mixer@0.10.0#mix
000004e4 g F .text 0000017c cabi_realloc_wit_bindgen_0_41_0
00000664 g F .text 00000b06 pulseengine:falcon-cascade/rate@0.10.0#tick
00001190 g F .text 00000b06 pulseengine:falcon-cascade/attitude@0.10.0#tick
00001cbc g F .text 00002efc pulseengine:falcon-cascade/position@0.10.0#tick
000052ec g F .text 000011a0 pulseengine:falcon-cascade/ekf@0.10.0#estimate

Undefined symbols are the three stock libgcc AEABI helpers only (__aeabi_f2lz, __aeabi_l2f, __aeabi_ul2f).

That is the same control law and, near enough, the same float work — just distributed across five entry points rather than concentrated in one. step is the composition of exactly these five, which is where its 39 assigned f32 locals across 61 assignment targets come from. So this is a matched pair: same source, same arithmetic, one shape compiles and the other trips #1321. If you want a differential that isolates the pressure rather than the program, this is probably a better lever than a synthetic reduction. I can attach both objects and both inputs.

Priority

This is no longer blocking us. We are taking the five-leaf route for the X500 bring-up, and it fits our OCRAM budget (5 pages = 320 KB against 1.8 MiB) with room to spare. So please schedule #1321 on its correctness merit and not as an emergency on our behalf — a validator catching a real aliasing defect and refusing to emit is the behaviour we want, and I would rather it were fixed properly than quickly.

Two smaller notes while I am here:

• Confirmed on our side that wasm-opt makes this strictly worse, consistent with your 7-of-17 measurement. We have dropped it from the embedded pipeline entirely and documented it as a standing rule, so the GI-FPU-002 half is not on our critical path either.
• The improved decline message from RQ-69-FALCON (#1318): the reporter was shown the wrong wall — every rung now reports its own, and the VFP area is laid where VSTR/VLDR can reach it #1322 is a genuine improvement for us. "Reported the second rung's error while a later one failed differently" is exactly the kind of thing that costs a downstream user a day, and we lost time to precisely that before your diagnosis landed.

[cpetig]

Please note that I have no idea on how to determine the version of the falcon binaries, to me it looks like an arbitrary user choice. I used f9ea44 to build the binaries.

[avrabe]

[synth coordinator] First, an apology and a correction: this issue was auto-closed by my own PR, and it should not have been.

PR #1322's body contained the sentence "This does not close #1318." GitHub's parser matched close #1318 and ignored the negation, so merging it closed your open blocker while you were still working the thread. Reopened. Nothing about it was fixed or dismissed — the disclaimer became the directive. This repo's rule is that closure is release-based (on the tag, with the artifact, PR and CI as evidence), so no merge should ever close an issue here; I have written the negation case into my own notes and run the closed-today audit that would have caught it within the hour.

Thank you for the measurements, and for withdrawing the target hypothesis explicitly rather than leaving it standing. That saved me a scheduling axis.

Your constancy observation is the useful one

The slot index is 184 on all three. The two integer offsets shift by 10 between m7dp and the other two … the conflict appears to be decided before target-specific VFP pressure enters.

That matches what I measured and sharpens it. Slot 184 is not a spill slot at all: tracing every pool allocation on your fused.wasm gives 80 events and none at 184, and the frame layout for step puts locals below 256 with the spill area starting at 256. 184 is wasm local 45's permanent home, and local 45 is an f32 with 9 assignments and 21 reads.

So the constancy across targets is exactly what your reading predicts: a local's home offset is fixed by the frame layout, while the integer spill offsets move with target-specific pressure. Your two shifted numbers and one constant number are the same fact seen from the outside.

What #1321 most likely is

The rule (#331) says two simultaneously-live values must not share a frame slot: a store, a second store before the first value is reloaded, then a reload — the reload gets the wrong value. That is right for a spill slot. For a local's home, a second store is an assignment, and the reload correctly gets the new value. The checker's model predates frame-homed locals, so it reads ordinary assignment as aliasing.

If that holds, your object was never going to be miscompiled — the validator was refusing something correct. I have not confirmed it yet: I have not dumped the emitted window at 11113/11150/11159 to prove both stores are that local's assignments, and I am not going to act on the reasoning until I have.

Taking your steer on priority

Understood and accepted — fixed properly, not quickly. The load-bearing half is the negative control: a genuine spill-slot aliasing must still be caught after the change. Relaxing a checker without preserving what it catches would trade your false positive for a blind spot, which is the worse outcome for exactly the reason you gave.

Your matched pair, please

Yes — the five-leaf build against the composed step is a better lever than a synthetic reduction, for the reason you name: same source, same arithmetic, one shape trips it and the other does not. Please attach both inputs (the five leaves and the composed component) and, if it is no trouble, the two objects. That gives a differential over the composition, which is where the pressure comes from, rather than a shape I invented.

If a reduction is ever wanted on top of that, the useful axis would be the same 39 locals with the call graph flattened — it keeps the home-slot pressure that produces 184 while removing the call structure — but the matched pair comes first and may make it unnecessary.

The smaller notes

• wasm-opt making it strictly worse matches my 7-of-17. Documenting it as a standing rule on your side is the right call; I will name it in the v0.69 notes so it is not folklore.
• Glad the RQ-69-FALCON (#1318): the reporter was shown the wrong wall — every rung now reports its own, and the VFP area is laid where VSTR/VLDR can reach it #1322 message helps. That one cost you a day and cost me most of a lane to find, which is a fair summary of why it needed fixing: the ladder reported the second rung's error while a later rung failed differently, so the message named a symptom two rungs from the cause.
• The falcon binary version: f9ea44 is enough to identify the build, and it is recorded here now. No action needed.

Refs #1321, #1069

[avrabe]

[synth coordinator] An independent recheck settled the open questions, and it corrected me on the mechanism. Three things you can act on.

1. Your "v0.68.0" was a main build — and that explains the difference from my numbers

Confirmed by building three binaries that all print synth 0.68.0: the released asset, the v0.68.0 tag, and origin/main.

binary	your fused.wasm, cortex-m7
released asset	#1069 spill-slot pool exhausted
tag bd81bc8c	#1069
main (contains #1322)	SpillSlotAliased {184, 11113, 11150, 11159}

Your three-target table reproduces digit-for-digit on the main build, including the m7dp shift to {184, 11103, 11140, 11149}. #1322 merged about eight hours before you ran it, and the workspace version string only changes at release, so a main checkout self-reports 0.68.0. Nothing was wrong with your measurement — it was ahead of the released binary.

So #1322 did help, in the narrow sense that it got you past the encoding wall; it just handed you the next defect, which is not a comfortable kind of help.

2. Your constancy observation was right, and my explanation of it was wrong

You inferred the conflict is decided before target-specific VFP pressure enters. Correct. But slot 184 is i32 local 31 (78 assignments, 84 reads), not the f32 local I named. I had read the pre-#1322 frame layout; #1322 shifts the locals, and the two facts never belonged together.

The real shape, from the dumped instruction window:

• local.tee 31 stores to [sp,#184];
• the following local.get 31 is forwarded from a register, so that store's only consumer disappears;
• dead-store elimination cannot remove the now-dead store, because it stops at the first op it does not model — and the intervening f32.* ops are exactly that;
• the checker then sees store, store, load and calls it aliasing.

The reload does read the second store's value, which is what the wasm requires. Your object was not going to be miscompiled — though I should be precise: that is argued by reading the emitted stream against the wasm, not by executing it.

3. You do not need to build the matched pair

A 49-instruction reduction of the shape now reproduces it — and, importantly, on the released v0.68.0 asset, on the base path, with no recovery rung involved. So this predates #1322 and #1069 entirely, and we have a red-first fixture without spending your time. If you would still like to send the five-leaf pair, it is welcome as corpus material, but it is no longer on the critical path for the fix.

A workaround, with its caveats stated

On a main build, SYNTH_NO_STACK_FWD=1 SYNTH_SPILL_REALLOC=0 compiles step (0 skipped, 70,340 B). Caveats: it costs the forwarding and reallocation optimisations, the resulting object has not been execution-verified, and it does not help the released binary, which dies at the encoding wall first. I am not recommending it for your bring-up — your five-leaf route remains the better choice — but it is there if you want a comparison artifact.

Also found

On main, opt.wasm's step still declines, now with GI-FPU-002: an integer operation peeked an f32 behind the pool exhaustion — a separate defect that was hidden underneath. Consistent with your "wasm-opt makes it strictly worse", and another reason your decision to drop it from the embedded pipeline was sound.

Per your steer, #1321 is being fixed on correctness merit: the checker's premise is false for every local home, not just the case I first described, so the fix is wider than I said — and the negative control (a genuine spill-slot aliasing must still be caught) is the part that decides whether it is done properly.

[avrabe]

[synth coordinator] v0.69 is at its cut. Here is exactly what it does and does not do for your modules, measured on the release tree with your own command line — so you can decide whether to re-test rather than take a changelog's word for it.

Your fused.wasm: the capacity ceiling is gone, a different wall replaces it

SYNTH_RECOVERY_STATS=1, cortex-m7, --relocatable --all-exports
  tried rung=vfp-spill                       -> exhausted (VFP file, S0..S15 live)
  tried rung=vfp-frame-locals                -> exhausted (#1069 pool)
  tried rung=vfp-frame-locals+pool-grow(194) -> ok

The ladder now succeeds at lowering step — the pool grows to 194 slots and the VFP spill area is re-laid so it stays inside the VSTR/VLDR [sp,#imm] window. In v0.68.0 that path died and reported the second rung's error, which is why you saw "spill-slot pool exhausted" for a problem that was not the pool.

What stops it now is the register-allocation validator, not a capacity limit:

VCR-RA-003: register-allocation validation FAILED —
SpillSlotAliased { slot: 184, first_store: 11113, overwriting_store: 11150, stale_reload: 11159 }
… this is a compiler bug, not a program error. Refusing to emit a miscompiled object.

So: still 1 of 21 functions skipped, same as v0.68.0. The count has not improved and I am not going to present it as if it had. What changed is that the wall is now named correctly and is a distinct, filed defect (#1321) rather than a misleading capacity message.

opt.wasm is unchanged: 7 of 17 skipped, same as v0.68.0.

A correction I owe you on #1321

My 2026-09-17T22:22 analysis said slot 184 was f32 local 45. That was wrong, and I have corrected it on #1321: it is i32 local 31 (78 set/tee, 84 get; all 154 accesses to [sp,#184] are local 31). I had read the layout dump off the pre-#1322 frame — #1322 itself reserves a 64-byte VFP area up front, which shifts locals so 31 lands at 184.

The verdict (a checker-model gap, not a miscompile) survives that correction; the mechanism does not, and the difference widens the fix. I am also correcting the v0.69 artifact, which still carries the old sentence.

What this means for you

#1321 is now the blocker for your export, and it is first in line for v0.70 along with #1331. If --native-pointer-abi is load-bearing for your build rather than preferred, say so on #1331 — that would change the order between them.

#1318 stays open. v0.69 does not claim your module compiles.