[nicolas-abril]

Closes #1240. #1413 already fixed that issue's GPU half: raytrace's and nbody's long loops are calls on the device. This PR fixes the half that remained, nbody on the CPU.

The bug

On the host every spin is INLINE. nbody's integration loop (spin_4: 15 KB, 21 F32 loop-carried words, one call site) is inlined into WL_FID_batch, whose setup computes four PRNG streams in 4-lane vectors. clang's SLP vectorizer carries those vectors into the loop: in the inlined build, 233 of the function's 571 instructions are vector or lane-shuffle ops, and two of the three pair kernels run as fsqrt.2s/fdiv.2s. As a separate function, the state arrives as 22 scalar arguments, SLP leaves the loop scalar (0 vector instructions in 313), and it runs 18% faster.

SLP is the whole difference. With -fno-slp-vectorize, the inlined build runs as fast as the call: 4.880 s against 4.840 s, and 5.746 s with SLP on. Register pressure, the guess in #1240, isn't the cause.

The fix

A spin of SPIN_FAR characters or more that loops (seg.spin) with an F32 among its live parameters is FAR, a call on both lanes. On the device FAR is what DFAR already was, so device programs don't change.

Across the 1,729 benches, demos and tests, 4 spins change, in nbody (spin_4), raytrace (spin_18) and app_slash_boss_3d (spin_39, spin_53). The emitted C of every other program is byte-identical to main, and every program builds or fails as it does on main.

Numbers

Apple M4, built with gates/perf.ts's cc lines, each cell the median of 5 interleaved runs, outputs identical:

bench	mode	main	this PR	speedup
nbody	SEQ-CPU	5.769 s	4.853 s	1.19x
nbody	PAR-CPU (16)	0.827 s	0.717 s	1.15x
nbody	PAR-GPU	0.159 s	0.159 s	1.00x
raytrace	SEQ-CPU	4.538 s	4.638 s	0.98x
raytrace	PAR-CPU (16)	0.713 s	0.727 s	0.98x
raytrace	PAR-GPU	0.365 s	0.365 s	1.00x

gates/perf.ts, alternating with main (4 runs each):

• nbody PAR-CPU: 0.717 s in both runs where the cell ran on this branch, against 0.831–0.835 s on main.
• raytrace PAR-CPU: 0.702–0.703 s against 0.691–0.695 s.
• GPU and COMPILER cells: within noise on both benches.
• Failing cells: 4–18 cells per run read err (exit 127 or an empty build error) on both main and this branch, in the same bench/mode pairs, nbody SEQ-CPU among them every time. That looks like a cluster problem, not this change.

bend -o time doesn't change: app_slash_boss_3d takes 9.59–9.84 s on main and 9.59–9.60 s here.

Alternatives measured and rejected

All 17 benches, SEQ-CPU and PAR-CPU (16):

rule	nbody	raytrace	rest
-fno-slp-vectorize	1.18x / 1.15x	1.00x	within ±3%
host FAR for every loop with F32 state	1.19x / 1.17x	0.75x / 0.76x	unchanged
host FAR for every loop	1.16x / 1.14x	0.75x	terrain 0.90x
empty-asm barrier on a float loop's inputs (inlined, but opaque to clang)	1.16x / 1.14x	0.73x	not run

• The broader FAR rules and the barrier: raytrace's spin_13 and spin_16 are 8-iteration F32 loops called once per ray. Inlined, clang unrolls and specializes them at each call site. Behind a call, or behind a barrier, it can't, and raytrace loses 25%. Requiring SPIN_FAR keeps them inline; only long loops become calls.
• -fno-slp-vectorize: matches this PR on nbody, but turns SLP off for every program. On synthetic loops with independent float lanes, SLP gains up to 1.48x as a call (8 lanes) and 1.18x inlined (4 lanes, as complex pairs). This PR keeps SLP on, and lets a long loop's vectorization depend on the loop body alone.

Checks

• Gates: repo 54/54, test 1697/1697, ping 72/72; perf as above.
• Size: comp.ts is 65,690 ttok (main 65,612, cap 66,000).

Not run: Linux/x86, CUDA hosts. app_slash_boss_3d builds but is interactive, so its two changed spins aren't timed.

🤖 Generated with Claude Code