jit-trace, interp: name the unpaired-address disarm; extra_tests: the getsizeof ABI split, an exact module-name oracle, and a slice script that runs - #1660
Merged
Conversation
… getsizeof ABI split, an exact module-name oracle, and a slice script that runs `disarm_unpaired_build_addrs` was called `reject_unpaired_build_addrs` in `pyre-interpreter/src/jit_fnaddr.rs` and `pyre-jit-trace/build/prepass.rs`, and both said it "refuses the load", which the function does not do: it writes zero over the address and leaves the body published. Its own doc justified zero as a value none of the pools' uses can mistake for a real target, a call through it faulting on the first instruction. Zero is instead what `jitcode.py JitCode.__init__ fnaddr=None` spells, and both consumers test for it before they branch: a call target goes through `is_callable_fnaddr`, so the blackhole declines it and hands the continuation back to the interpreter while the walker declines it as `ResidualDecline::Symbolic`, and a type operand is only ever compared, so a comparison matching no object fails the guard reading it. `stdlib_sys` charged a two-word `PyGC_Head` to every collector-tracked type. That header exists only in a build with a global interpreter lock; without one the collector keeps its bits in the object header, which is what `get_sizeof` implements and what `Py_GIL_DISABLED` names, so the expectation reads that config var and each interpreter asserts the layout it was built with. Behind that assertion sat a second one, which now fails here and says why: `sys__getframemodulename_impl` reads `PyFunction_GetModule(f->f_funcobj)`, so a `__module__` reassigned after definition is what CPython answers, while a frame here carries the globals it executes in and no link back to the function. `pypy/interpreter/pyframe.py class PyFrame` carries none either -- its `createframe(code, w_globals, outer_func)` takes the function to read its closure alone -- so closing this is a frame-model change rather than a missing port, and the assertion states CPython's answer rather than accepting both. The script is not gated, so the failure is recorded where it is read rather than turning a run red. `builtin_slice` called `test_all_slices`, which imported a `cpython_generated_slices` module that has never existed in this tree, so the script ended in ModuleNotFoundError on every runner. The function is removed rather than given the table it wanted: every question it asks is answered more widely by `test.test_slice`'s `test_indices`, which the CPython suite gate runs and records as PASS, and which walks `itertools.product` over twelve start/stop/step values against six lengths -- including `2**100` bounds and the zero length -- against a reference implementation. What remains is the slice construction, repr, comparison, subscript-protocol and `__index__` coverage that the suite does not carry, and the script now passes under cpython, dynasm and cranelift for 0.4s, so it carries `gate=1`. Assisted-by: Claude
|
Warning Review limit reachedNext included review available in 2 minutes. View limit detailsLimit details: You’ve used all 2 included reviews currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Team Run ID: 📒 Files selected for processing (5)
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. Comment |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
🤖 Codex parity reviewStatic analysis of this diff vs the local RPython/PyPy sources (commit 81a25af). Files in the reviewed diffCodex did not produce a report (exit 1). Last log lines: |
Contributor
Merging this PR will not alter performance
Comparing 
Footnotes
|
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.
Re-lands the part of #1651 that outlived it. That PR's merge commit
557d6de9db5is not an ancestor ofmain; of the last fourteen merged PRs it is the only one whose merge is missing, so the drop was specific to it rather than a history rewrite. Two of its four subjects should not come back, and do not:cpython_generated_slices.pytable. Every questiontest_all_slicesasks is answered more widely bytest.test_slice'stest_indices, which the CPython suite gate runs and records as PASS, and which walksitertools.productover twelve start/stop/step values against six lengths -- including2**100bounds -- against a reference implementation. The function is deleted instead of given its table.max-pypy-ratiorefits. check: subtract pypy's startup from every pyre backend; bench/synth: lengthen 41 fixtures and record the missing jit-stats #1653 changed what a ratio measures: every pyre backend now subtracts pypy's startup rather than its own, soratio_new = ratio_old + Δ / pypy_execwith Δ = 0.053s-0.110s. Both refits were fitted from readings taken under the previous subtrahend, which that PR's own message rules out as evidence, and both pointed against the correction's sign.loop_callee_shared_mutationandload_name_builtin_cell_foldare left exactly asmainhas them, and check: subtract pypy's startup from every pyre backend; bench/synth: lengthen 41 fixtures and record the missing jit-stats #1653 already recorded the tworange_step_one_shapesjit-stats baselines byte-for-byte identically.What remains is three doc comments and two snippets.
git diff main..HEAD -- '*.rs'contains no non-comment line, so nothing here can move a benchmark.One reading this leaves open
load_name_builtin_cell_foldis not among the eight ceilings #1653 refitted, and the same arithmetic moves it toward its own. Its readings were 0.4x-2.4x against a ceiling of 2.5 and a derived floor of 0.417, with pyre's execution flat at 0.28s-0.37s and pypy's spanning 0.15s-0.54s -- the spread is the denominator's. Under the new subtraction the low reading pairs with the slow pypy and rises to 0.50x-0.60x, clearing the floor, while the high reading pairs with the fast pypy and rises to 2.75x-3.13x, over the ceiling.main's own run at 6aabe92 was cancelled, so no measurement of this exists yet. It is named here rather than refitted, because refitting a gate from a prediction is the error this PR removes.