falcon cascade still declines on cortex-m7dp at v0.66.0 — GI-FPU-002 on the single tick function (21 of 22 lower)

[avrabe]

Summary

On synth v0.66.0, the falcon flight cascade compiles almost completely for
--target cortex-m7dp: 21 of 22 functions lower, including 1408- and
1468-byte ones. Exactly one declines — the exported tick — with:

GI-FPU-002: VFP register file exhausted (S0..S15 all live) — f32/f64 register
pressure exceeds the file; the backend retries with VFP spilling (#881) and
this surfaces only if that also fails

#881 is closed, so this is a report that the case it covers still reproduces
on the current release with a real workload.

Reproduce

synth compile falcon_cascade_cm.wasm --target cortex-m7dp --all-exports -o out.elf

The component is the published falcon cascade (pulseengine:falcon-cascade@0.10.0),
a single step export wrapping the whole flight core — IEKF estimator,
geometric SE(3) attitude, ADRC inner loop, mixer with rotor-out FDI, plus the
altitude and position loops. It is float-heavy by construction and the tick is
one large function after inlining.

Target sensitivity (same input, same synth)

target	functions skipped of 22
cortex-m7dp	1 (the tick only)
cortex-m4f	3
cortex-m7	3
cortex-m3 (no FPU)	16

What we tried on our side, and why it did not help

Register pressure is arguably ours, so we split the export into a thin
forwarder plus an #[inline(never)] body. The decline simply moved with the
body:

warning: skipping function 'func_1': ... GI-FPU-002 ...
Error: #1102: 1 retained function(s) relocate against function(s) this compile
DECLINED: 'controller@0.10.0#step' -> 'func_1'

So the pressure is inherent to the tick body — where FlightCore::step inlines
the full cascade — and not to the export boundary. Splitting at the seam cannot
fix it; it converts a partial object into an unlinkable one. Reducing it from
our side would mean forcing #[inline(never)] on the flight core's internal
stages, which changes the code we verify and fly, so we would rather ask first.

Question: is per-stage #[inline(never)] in the guest the intended remedy
for GI-FPU-002, or is VFP spilling expected to cover a tick of this size?

Credit where due — two refusals behaved exactly right

Both #952 (partial object) and #1102 (unlinkable object) exited non-zero
with an explicit explanation rather than shipping something a $? gate would
accept. That is the correct behaviour and it is what made this diagnosable in
one pass.

Context

Asked by a colleague evaluating the meld+synth firmware route for a Pixhawk
6X-RT / H7 airframe: "validate a trivial float path through
synth compile --cortex-m → Renode before committing the firmware rewrite to
the schedule." Trivial float paths lower correctly — verified vmul.f32,
vadd.f32, vdiv.f32, vsqrt.f32 with the hard-float ABI on m7dp — so #369
and #708 are genuinely fixed. This tick is the remaining gate.

[avrabe]

Neither, and thank you for asking before changing the code you fly — the answer is a defect on synth's side, not a guest-side tuning problem.

The register file is not exhausted when that error fires. Half of it is unused.

Derived from the source rather than from the message:

where	what it says
synth-synthesis/src/instruction_selector.rs	vfp_home: &[bool; 16], let mut set = [false; 16], and the doc comment "These reside in S0..S15, which are AAPCS-VFP CALLER-saved"
synth-backend/src/arm_encoder.rs	already encodes VfpReg::S0 through VfpReg::S31 — the upper half is encodable today
the encoder, searched for VPUSH/VPOP	no matches anywhere
synth-synthesis/src/liveness.rs:5977	"D8..D15 are CALLEE-saved, out of scope for a caller-side check"

Every FPU target synth supports — FPv4-SP-D16 on M4F, FPv5-D16 on M7 — has D0-D15 = S0-S31. synth allocates inside S0-S15 / D0-D7 and never touches the other sixteen. The reason is structural rather than arbitrary: S16-S31 / D8-D15 are AAPCS callee-saved, so using them requires a VPUSH/VPOP prologue that the encoder cannot currently emit. So the guard is telling you the truth about the half it can see, and the message is misleading about the hardware.

That also explains your target sensitivity table exactly: the cap is the same 16 registers on every FPU target, so what varies between m7dp, m4f and m7 is only how much each one costs per value, not how many are available.

Your workaround could not have worked, and that is informative

You split the export into a thin forwarder plus an #[inline(never)] body and the decline moved with the body, turning a partial object into an unlinkable one. That is the correct outcome for the code as it stands: the pressure is in the tick body, and no seam you introduce upstream of it changes how many registers the allocator believes exist. Per-stage #[inline(never)] in the flight core would be you paying, in code you verify and fly, for a limit that is ours. Please don't.

VFP spilling was likewise never going to cover a tick of this size. The #881 ladder and its #1069 frame-homed-local follow-up both work — v0.66's mutation survey confirmed by execution that all three rungs actually fire on cortex-m7dp — but they are spilling to memory against half a register file, which is the expensive remedy applied to the wrong constraint.

What we are doing

Filed as RQ-67-VFPREACH in the v0.67 plan (PR #1268), priority must: teach the encoder VPUSH/VPOP for the AAPCS callee-saved VFP set and let the allocator use S16-S31 / D8-D15 behind a prologue that saves them.

Two commitments in the artifact's done-when, both aimed at you specifically:

• Your tick gets measured again, on cortex-m7dp, and we publish the function count that lowers whether or not it reaches 22 of 22. If pressure remains after the file doubles, you get the measured remaining number, not a restatement of the cap.
• Nothing that lowers today moves a byte. The wider file is admitted only on paths that would otherwise decline, gated on byte-identity over the corpus — the same discipline the #881 rung already uses ("deliberately LAST, so any function that compiled yesterday is produced by exactly yesterday's path").

It turns out to be the same shape as v0.67's other headline, one register file over. On the integer side the prologue saves R4-R8 while the allocator hands out R9-R11, so a callee-saved register gets clobbered — a silent wrong answer (#1204). On the float side nothing saves D8-D15, so the allocator refuses to hand them out at all — a loud decline. One root shape, the callee-saved contract and the allocator disagreeing about which registers exist, failing in opposite directions.

On the two refusals

Noted, and it goes in the release notes rather than only here. #952 and #1102 exiting non-zero with an explanation is the behaviour this project claims as its differentiator against compilers that accept everything and are quietly wrong on some of it. You got a diagnosable answer in one pass because of it, and that is the argument, made by a user instead of by us.

Refs #1267