perf(codegen): three independent commits from #9395 - #9433
Merged
Conversation
added 4 commits
September 1, 2026 20:06
… proof (444 -> 94 ms) `collectors/ptr_shape_numeric.rs` proved `view[i]` is Number-or-`undefined` from two sources: `numeric_ta_views` (spec-proven `TaPtr` parameters) and `const_local_inits` (a compiler-visible `const` init in the SCANNED body). A module-global `const buf = new Uint8Array(N)` read inside a function has neither, so `acc += buf[i]` lost the accumulator's Number-by-construction proof and every add lowered through the rooted `guarded_add` diamond: a GC shadow-frame load + store + `js_write_barrier_root_nanbox` per element, plus the dynamic-add cold arm. `module_global_proven_types` is the same STRENGTH of proof as `const_local_inits` — derived from the initializer expression on a single- `Let`, never-reassigned binding, not from an annotation (Perry does not enforce those, #7773) — so module-scope views whose construction proves a number-valued typed-array kind now feed the same fixpoint slot. The BigInt kinds are deliberately excluded: their elements are BigInts, not Numbers. Measured (SIZE=1e6 x ITER=100, quiet host, min-of-3): the identical loop over a module-global receiver 444 -> 94 ms, exactly matching the body-local receiver it should always have matched, against node's 79. The receiver's binding form is no longer observable in the emitted loop. ATTRIBUTION, corrected by measurement. The missing proof also leaves a per-iteration `load volatile @PERRY_GC_POLL_ARMED` in the loop, because `loop_may_allocate` stays conservative while the `+` is not inert, and the obvious story is that this volatile load blocks vectorization. It does not pay: admitting the read as inert under the same construction proof (so the poll leaves the loop) measured 94 ms either way, and did not vectorize either — the residual blocker is #9360's per-element admission-cache probe. That change is therefore NOT included: `expr_is_inert_primitive` also governs rooting decisions, and an unmeasured widening of it does not ship. The residual is documented in the test and in #9363. Tests: `issue_9363_module_global_view_numeric_proof.rs` pins the emitted shape against a body-local control (which is asserted clean first, so the comparison cannot pass vacuously) and pins that a REASSIGNED module global is still not admitted — the construction proof's exclusion is load-bearing. Claude-Session: https://claude.ai/code/session_01NbKbYm54HW6cHwEx5FZAtP
…typed_array_untyped_access 1216 -> 257 ms, node 290) `collectors/int_valued_ta_locals.rs` exists for bcryptjs `_encipher` — its module doc IS that function — but rejected its own subject's accumulator. The wrap-i32 additive arm was admitted only for a STRAIGHT-LINE (never in-loop) Add/Sub tree, and `n += S[...]` sits in the Feistel `while`. So `n` stayed an f64 slot holding nothing but int32 values, and every S-box step emitted `sitofp` in and `llvm.aarch64.fjcvtzs` out around the `fadd`. WHY THE RESTRICTION WAS TOO COARSE. Its stated hazard is real: an unbounded in-loop chain can carry the true f64 value past 2^53, where it ROUNDS while an i32 slot WRAPS, and rule (2) only guarantees the `ToInt32` image is observed — so the two would then disagree. A per-iteration re-seed removes exactly that hazard, and needs no dominance argument: if the body unconditionally assigns the local a fresh exact-i32 value once per iteration, the chain restarts every iteration no matter WHERE the re-seed sits, so the magnitude never exceeds one body's worth of addends. With each addend below 2^31 a body would need ~4M additive writes to reach 2^53; `_encipher` re-seeds and adds twice, so `|n| < 2^33`. The scan is deliberately narrow. The re-seed must sit at the loop body's TOP level: one nested in an `if`/`switch`/`try` may not run on a given iteration, which is precisely the case where the chain keeps growing. Nested loops are scanned as their own bodies, so an inner loop's re-seed never bounds the outer body's chain. MEASURED (quiet host): typed 1216 -> 257 ms and untyped 1254 -> 258 against node's 290 / 299 — from 4.2x slower to faster than node on BOTH paths. The fixture's own checksum oracle, which throws on any divergence between the typed and untyped states, passes identically. This was the last suite row above node. VERIFIED, and one honest gap. The promotion DECISIONS were checked directly through `PERRY_REPSEL_DEBUG`: `n` is promoted in both `encipher` bodies and in an unconditionally-reseeded fixture, and is refused for a loop with no re-seed, one whose re-seed is `if`-guarded, and one whose re-seed is in an inner loop. Node-differential battery (including those adversarial shapes) byte-identical, and identical again under `PERRY_GC_HEAP_LIMIT=8 PERRY_GC_FORCE_EVACUATE=1`. I could NOT prove the conditional-re-seed guard independently load-bearing: I sabotaged it (letting `if`-nested re-seeds count) and failed across three fixture attempts to construct a case whose outcome changes — each failed for a different reason (rule (2) rejected the local first; power-of-two addends made wrapped and exact coincide; a module-global receiver did not reproduce the spec-param admission conditions). So it is defense-in-depth of unproven necessity, stated rather than claimed — the same honesty `loop_safepoint_purity.rs` applies to its own shadow-slot half. Tests: `issue_9363_loop_reseeded_accumulator.rs` pins the Feistel round against node and pins that the three unbounded shapes stay f64, with the oracle itself guarded (the fixture asserts its expected values still exceed i32 range, so a wrongly promoted local would print a wrapped negative rather than a near miss). Claude-Session: https://claude.ai/code/session_01NbKbYm54HW6cHwEx5FZAtP
…ric_array_numeric 45 -> 38 ms, node 38) `stmt/loops.rs` already skips the back-edge poll inside three loop-clone fact scopes, and its comment states the rule and predicts this exact case: a poll exists so an ALLOCATING body can defer a collection; `loop_may_allocate` answers from the HIR, where `arr[i] = e` is a generic `IndexSet` that CAN reallocate; and inside a fact scope codegen knows better, because the clone is call-free or it is not entered. The packed-f64 clone is that body and was simply not listed. Its entry guard proves a live packed raw-f64 plain Array with the loop window in bounds, its reads and writes lower to bare `double` load/store over existing slots (so nothing grows, reallocates, or writes a heap edge), and its matcher admits no calls, closures or awaits into the body — the same conjunction the three listed clones rest on. This is therefore not a new licence. WHY IT COST MORE THAN ITS OWN INSTRUCTIONS. The armed word is loaded VOLATILE, which is a clobber inside the loop, so the cached packed receiver base had to be re-derived on every element — the effect #9316's stride comment already describes. That is why striding the poll 1-in-64 did not recover the loss while removing it does: the cost was the clobber, not the frequency. MEASURED (250k x 250, quiet host, min-of-3): 45 -> 38 ms against node's 38. A forced-arm build with polls disabled entirely also lands on 38, so this recovers the whole gap and nothing more — the diagnostic bounded the win before the change was written. Tests: `issue_9379_packed_f64_clone_poll.rs` asserts no poll inside the CLONE's own blocks (module-wide counting would assert something this change never claimed — the fill and outer loops keep their polls), with a vacuity guard that the fixture still admits the tier, and correctness under `PERRY_GC_FORCE_EVACUATE` + `PERRY_GC_VERIFY_EVACUATION`, which is the arm that matters when a safepoint is removed. A sibling test pins that an allocating loop still polls, so the skip stays scoped to the fact. Both assertions in the first draft were wrong and perry was right: I counted polls module-wide, and I hand-computed an expected checksum incorrectly. Both now use node as the oracle or the clone's own region. `loop_safepoint_purity` 8/8 and codegen 1379/1379 green. Claude-Session: https://claude.ai/code/session_01NbKbYm54HW6cHwEx5FZAtP
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Lands the part of #9395 that does not depend on the still-broken #9360. Author's commits preserved.
#9395 is a seven-commit stack on #9360, whose base commit
3715f58d5fregressestest_gap_typedarray_buffer_aliasing_7219(4 3 2 1→4 0 0 0). Rather than hold the whole stack, these three are independent of it:778695084e— a module-global typed-array receiver earns the numeric proof (444 → 94 ms)d205ad3989— a loop-reseeded accumulator earns its i32 slot (1216 → 257 ms, node 290)1ebfd82326— the packed-f64 loop clone needs no GC poll (45 → 38 ms, node 38)Two commits are deliberately left behind, because they genuinely depend on the broken base:
70df878c02(DECLARED typed-array parameter inline element load) modifiesexpr/u8_buffer_read.rs, a file that only exists once In-function Uint8Array reads are 12x slower than the identical top-level loop (560 vs 46 ms) — and the obvious fix returns wrong answers #9342's base commit creates it — the cherry-pick reportsDU.5ece939298(vectorize bounded byte-sum reductions) introduces a tuple whose second element is consumed by70df878c02. Taking it alone compiles with twounused variablewarnings, i.e. it would ship half a feature. I checked that rather than silencing the warnings with a_prefix.#9395's concat-memo commit is already on
mainvia #9397.Validation:
perry-codegen+perry-runtimegreen (39 suites) underRUST_TEST_THREADS=1; release build clean with no warnings — which is the specific check that told me where the stack could be cut; file-size, raw-handle (bare and--no-raise-vs), census, root-holder, addr-class, thread-local, unrooted-local and fmt gates all pass.