perf: the loop-hoisting tiers only admit single-statement, call-free bodies — a 6x store-path win produces 0.000% on real programs

[proggeramlug]

The finding

perry's loop-hoisting tiers — the ones that lift a loop-invariant array receiver proof into the preheader, and the reason #10731 took an indexed read from 87 instructions to 13.5 — only admit loop bodies that real programs do not have.

A store-side fix measured on microbenchmarks takes an Array element write from 105 instructions to 17.4 and a[i] = a[i] + 1 from 256 to 24.5. Applied to five realistic programs it moves none of them:

program	base	fix	delta	vs node
tok	839,745	839,749	+0.000%	0.28×
sim	529,908	529,908	0.000%	0.04×
graph	4,217,041	4,218,055	+0.024%	0.12×
records	1,957,614	1,957,074	−0.028%	0.45×
text	92,313	92,313	0.000%	0.77×

Per-op, fitted across two sizes. sim and text are identical to the instruction; the rest is fit noise.

Why — traced, not inferred

PERRY_PACKED_LOOP_TRACE on the fix arm:

• sim — 3 × [range-loop] rejected: body_not_admissible. Its inner loop is five statements containing two ifs. The classic tier takes one statement; the multi-statement (dense) tier is read-only, because a mid-iteration side exit would re-execute stores that already ran. Annotating all four arrays as number[] changes nothing — still body_not_admissible. Callgrind: 1,239 instructions per particle step for ~4 compound-assign element stores and ~6 reads.
• graph — 3 × body_not_admissible, plus bound_shape_unsupported and array_kind_unknown. Its hot loop calls q.push(v) and indexes dist[v] with a data-dependent index. A call in the body can invalidate the hoisted head, so no current tier can admit it.
• tok / records / text — string, Set and object work; element stores are not their cost.

The general shape

The admissible set is roughly: a single-statement body, no calls, no conditionals, a statically-shaped bound. Real loop bodies are multi-statement, call things, and branch.

So the tiers deliver their full benefit exactly where a benchmark is written and not where a program is. That is why a 6× improvement on the store primitive produces 0.000% on sim, whose inner loop is entirely element stores — it is simply five statements long.

What would actually be needed

Two things, both real compiler work rather than a patch:

1. A multi-statement tier that admits stores. The blocker is the mid-iteration side exit: if the guard fails partway through an iteration, stores that already executed must not be re-executed on the fallback path. That needs either a checkpoint/rollback discipline or a proof that the guard cannot fail mid-iteration once it has passed at entry.
2. Admitting calls in the body. A call can invalidate the hoisted receiver head. That needs an effect analysis strong enough to prove a given callee cannot reach the array — or a cheap re-validation on return that still beats re-proving per element.

Why this is filed separately

Both are larger than one pass, and I would rather have this written down than have someone conclude from #10731 and the store work that array access is solved. On the primitive it is; on real programs it is not, and the gap between those two statements is this issue.

Measured on perrymaster, perry from origin/main + #10731, node v26.8.1, bun 1.4.2, all five programs byte-identical across runtimes.

Related: #10718 (the per-element costs), #10731 (the read side, landed as far as the primitive goes), #10695 (where perry stands on real programs, and the crossover model).

[proggeramlug]

Evidence that this is broader than arrays: typed arrays do not escape it either

A natural reading of this issue is "ordinary arrays are the problem, typed arrays are the workaround." They are not.

I rewrote the particle simulation using Float64Array throughout and expanded assignment (vy[i] = vy[i] - 0.0098) instead of compound, i.e. avoiding both #10718's ordinary-array cost and #10743's compound-assign lowering. Identical physics, byte-identical output in all three runtimes.

N	perry	node	bun	vs node	vs bun
1,000	53,259,312	158,185,652	150,520,167	2.97×	2.82×
10,000	553,032,775	348,588,675	366,017,243	0.63×	0.66×
100,000	5,551,522,434	2,243,952,838	2,260,005,273	0.40×	0.40×

Per particle-step, fitted 10k→100k: perry 138, node 52, bun 52 — perry 2.65× slower.

That is the striking part, because in isolation perry wins every primitive this loop uses:

primitive, isolated	perry	node	bun
Float64Array read	6	10.2	10.6
Float64Array write	8	11.5	16.1
bare loop	4	7.8	7.6

The loop performs roughly 15 typed-array accesses per particle-step. At the isolated costs that predicts ~100 instructions and a comfortable win; measured, it is 138 against node's 52. node's per-access cost inside the real loop is a third of what it is in the microbenchmark; perry's is unchanged.

That is the whole issue in one measurement. A JIT that sees a five-statement branchy body still optimises across it — hoisting, scheduling, keeping values in registers across statements. perry's tiers decline the body entirely and fall back to per-statement code that is individually good and collectively unimproved.

Consequence for how this gets prioritised

Fixing ordinary-array access (#10718, #10731, #10746) and the compound-assign lowering (#10743) are all worth doing — they are real defects with real numbers. But none of them, nor all of them, makes a realistic loop competitive, because the deficit survives even when every primitive in the loop is one perry already wins.

The crossover model in #10695 still holds: perry wins below a program-specific size on its startup advantage and loses above it on throughput. This says the throughput half is gated on admitting real loop bodies, not on the cost of any individual operation.