jit: store-loop header merge-point forward-select + list-subscript exact-type guards + int-subclass BigInt

[youknowone]

Six commits on top of main (the FOR_ITER abort-free heap-store admission from this line already landed via #448 and was dropped during rebase).

Commits

• jit: publish STORE_SUBSCR residual exception to backend cells — bh_store_subscr_fn publishes a raise into both BH_LAST_EXC_VALUE and the backend _store_exception cells, so a compiled trace's trailing GuardNoException side-exits instead of reading a stale 0 and swallowing the raise. Mirrors bh_store_attr_fn / jit_next.
• jit: guard exact list type in subscript read/store specializations — walker-native list get/setitem gate on is_exact_list and emit a runtime walker_guard_exact_w_class (PtrEq on the canonical w_class) so a list subclass that shares ob_type == &LIST_TYPE but overrides __getitem__/__setitem__ side-exits to the generic residual rather than taking the direct-storage path.
• jit: forward-select loop-header merge point for header-entry traces — a header entry selects the FIRST merge point at/after entry (min{mp_pc >= entry}) instead of the last one before it; the old max{<= entry} picked a preceding sibling loop's merge point, seeding that loop's green colors and leaving this loop's pycode color OpRef::NONE (the "born-between-loops" JitMergePointGreenKeyUnresolved abort). Body-guard bridge resumes keep max{<= entry}. header_entry_is_nested scopes the change out for a loop nested inside another still-active loop, keeping nested inner loops on the interpreted path (their bridges are separately miscompiled — see Split descr identity between metainterp and backend #36).
• jit-trace: exact-w_class guard on residual/trait list setitem path — adds a default WalkerFrameOps::guard_exact_w_class and calls it in generated_list_setitem_by_strategy, extending the exact-type guard to the residual/trait store helper (defense-in-depth; the live getitem helper is retired-path only and documented in place).
• interpreter: preserve BigInt magnitude for int-subclass instances — int_descr_new branches on is_long, cloning the BigInt into w_long_new for magnitudes that overflow i64 (the i64 fast path truncated them to a garbage machine word).
• style: apply rustfmt to walker_frame_ops exact-w_class guard.

Verification

• cargo build --release (dynasm) clean; python pyre/check.py --backend dynasm → ALL PASSED: dynasm 161/161.
• Store-loop benches (prefix / histo / matfill / sieve / copy_scale): 0.78–0.95x regressions → 5–13x, driven by the merge-point fix letting the second sibling loop compile.
• Nested adversarial shapes (for-in-while / for-in-for / while-in-for / triple / mixed siblings) byte-identical JIT vs PYRE_NO_JIT=1.

Codex parity review

Ran against the true fork point: Section 1 & 2 = None (no new parity regressions or mismatches). Section 3/4 findings are all documented adaptations or accurately-documented unreachable pre-existing items (dispositions recorded in .claude/codex-review-report.md). Follow-ups filed: #36 (nested-loop bridge exact-resume), #35 (rvmprof port).

— commented by Claude

[coderabbitai]

Warning

Review limit reached

@youknowone, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 37 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 1fd99681-6726-46de-8c4b-3d451278f62d

📥 Commits

Reviewing files that changed from the base of the PR and between a67d249 and 0124a3a.

📒 Files selected for processing (7)

• majit/majit-backend-wasm/src/lib.rs
• pyre/pyre-interpreter/src/opcode_ops.rs
• pyre/pyre-interpreter/src/typedef.rs
• pyre/pyre-jit-trace/src/jitcode_dispatch.rs
• pyre/pyre-jit-trace/src/trace.rs
• pyre/pyre-jit-trace/src/trace_helpers/typed_trace.rs
• pyre/pyre-jit-trace/src/walker_frame_ops.rs

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch test-math-parity

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

🤖 Codex parity review

Static analysis of this diff vs the local RPython/PyPy sources (commit 0dd0caf).

1. Regressions to PyPy parity introduced by this patch

None.

2. Other mismatches introduced by this patch

None.

3. Pre-existing mismatches (already present before this patch)

• pyre/pyre-jit-trace/src/trace_helpers/typed_trace.rs:1818 ↔ pypy/objspace/descroperation.py:356 — the active trait tracer emits only guard_class(LIST_TYPE) before direct list-storage reads. A list subclass shares that payload type but PyPy dispatches __getitem__ through special-method lookup; a later subclass value can pass the guard and bypass an override. The patch correctly filters the trace-time object at typed_trace.rs:1901, but does not add the needed runtime w_class guard to this active path.

• pyre/pyre-jit-trace/src/trace_helpers/typed_trace.rs:1888 ↔ pypy/objspace/descroperation.py:356 — exact-tuple filtering occurs only while recording. generated_tuple_getitem subsequently guards the storage ob_type, not canonical Python class identity, so a tuple subclass can enter a trace recorded for a plain tuple and bypass an overridden __getitem__. This existed before the patch; the new trace-time is_exact_tuple filter does not close the compiled-trace guard hole.

4. Structural adaptations

• pyre/pyre-jit-trace/src/trace.rs:430 ↔ rpython/jit/metainterp/pyjitpl.py:1537 — Pyre reconstructs merge-point register colours by decoding JitCode around a resume PC, whereas RPython’s MIFrame executes the jit_merge_point directly. The patch’s header/body selection is an implementation-language/resume-model adaptation.

• pyre/pyre-jit-trace/src/trace.rs:421 ↔ rpython/jit/metainterp/pyjitpl.py:1537 — nested-loop header entries deliberately retain the old, declining behavior because Pyre’s walker cannot yet safely compile nested-loop closing bridges. This is an explicit conservative limitation, not a 1:1 PyPy port.

• pyre/pyre-interpreter/src/opcode_ops.rs:680 ↔ rpython/jit/backend/llsupport/llmodel.py:194 — publishing a residual-call exception to both BH_LAST_EXC_VALUE and backend exception cells is required by Pyre’s shared Rust helper ABI; RPython keeps metainterpreter state and backend exception storage separate.

• pyre/pyre-interpreter/src/typedef.rs:1294 ↔ pypy/objspace/std/intobject.py:1097 — Pyre preserves an int subclass’s value by allocating either Rust W_IntObject or W_LongObject and retagging w_class; PyPy uses allocate_instance/newbigint. The changed long-value branch is semantically aligned with PyPy’s W_LongObject branch.