Latest Results
majit-backend-wasm: the two metadata opcodes the catch-all declined on
`JitDebug` and `RecordKnownResult` had no codegen arm, so they reached the
catch-all. A void op's `pos` is `OpRef::NONE`, whose raw is `u32::MAX`, and
`raw_is_constant` rejects the sentinel range, so the catch-all's guard holds
and the whole trace is declined rather than emitting nothing. Both native
backends list the pair among the ops they skip: dynasm in `regalloc.rs`'s two
`RegAllocOp::Skip` arms, cranelift in its "Debug / no-op operations" arm.
Neither owes code. `consider_jit_debug` is `pass` — the effect is in the
recorded trace, not in emitted instructions. `RECORD_KNOWN_RESULT` has no
backend arm upstream at all: `optimize_RECORD_KNOWN_RESULT` consumes it and
simplify drops it.
Both are latent today: `jit_debug` has no caller outside its own definition in
`majit-metainterp/src/jit.rs`, and simplify removes `RecordKnownResult` before
the backend.
The catch-all's message named the shape "value-producing", which is the one
thing it is not for a void op — the arm rejects those too, and that wording is
what reads as "a void op is silently skipped here".
cargo test -p majit-backend-wasm: 87 passed, 6 ignored.
Assisted-by: Claude bench/synth: refit four pypy ceilings the startup subtraction moved, and retire a fifth (#1666)
* bench/synth: refit exception_loop_warmup's ceiling, which the startup subtraction moved
`6aabe927ce1` made every pyre backend subtract pypy's startup rather than its
own, so the startup a pyre process spends above pypy now stays in the
numerator. 4.1 was fitted before that, and this fixture's pypy execution is
0.05s-0.09s -- one to two times FLOOR_GATE_MIN_BASELINE_S -- so the 0.053s-0.110s
that lands on it is comparable to the whole baseline it divides. It was not
among the 41 fixtures that commit lengthened or the 8 whose ceilings it refitted.
Readings on run 33651833695, which measures it under the new subtraction for
the first time -- `main`'s own run at 6aabe927ce1 was cancelled:
ubuntu cranelift 5.0x (median of 3; the failure)
wasm 4.4x
dynasm 3.3x
macos cranelift 3.6x
dynasm 2.9x
windows dynasm 5.0x (marked `?`: the floor declines this baseline)
6.5 covers the widest with 1.3x to spare, and the floor it derives -- capped at
parity, since 6.5/6 is above 1 -- sits 2.9x under the fastest reading.
Not lengthened. Doubling the trip count takes pypy's execution from 0.05s to
0.10s, which is the 2x bar rather than past it, and leaves a predicted 4.7x that
needs this refit anyway; a length that clears the bar with margin puts the
windows dynasm leg over a second for one fixture. The recorded jit-stats are
not what argues against it -- measured at both 7840000 and 15680000 on dynasm
and cranelift, loops_compiled=1, bridges_compiled=2 and guard_failures=402 are
identical, and both match the committed baselines.
The same subtraction leaves siblings in the same position: `gate` and
`jit-gc-resume-gaps` both fail this job on `for_iter_conditional_store_bridge`
at 4.8x and 4.5x against a ceiling of 4, with pypy at 0.04s and 0.06s. Those
are not touched here.
Assisted-by: Claude
* bench/synth: refit three more ceilings the startup subtraction moved, and retire a fourth
`exception_loop_warmup` was not alone in the position `6aabe927ce1` left it in,
and refitting it alone moved the failure rather than removing it: the same job
then failed `for_iter_conditional_store_bridge`, which is what `gate` and
`jit-gc-resume-gaps` had been failing on all along.
Fitted from 12 CI runs created after that commit -- readings from before it
subtracted a different quantity and are not evidence about these gates. Only
unmarked rows are used. A `?` row carries a granularity buffer worth
EXEC_TIME_FLOOR_S over its baseline, which is what lets it print a ratio far
above its ceiling without failing, so counting one would fit the gate to a
reading that cannot fail it; every one of these fixtures has its widest reading
on such a row, on windows dynasm or ubuntu wasm.
Each ceiling has to cover the widest unmarked reading and derive a floor
(ceiling/6, capped at parity) under the narrowest, which fixes a window:
for_iter_conditional_store_bridge 1.6x-5.1x n=55 window 5.1-9.6 4 -> 7
condexpr_heap_const_merge 2.2x-6.6x n=54 window 6.6-13.2 4.2 -> 9
for_iter_nested_method_inline 0.9x-3.6x n=61 window 3.6-5.4 3.3 -> 4.4
`for_iter_method_branch_inline` loses its ceiling instead. Its unmarked
readings span 0.8x to 4.5x over 60 observations, a factor of 5.6 against a
PERF_GATE_FLOOR_DIVISOR of 6, which leaves the window 4.5-4.8 -- six percent
wide, with under three percent of margin at either end. A bound that narrow
over that many samples reports the runner rather than the code. The spread is
the denominator's: pypy executes this loop in 0.30s on macos and 0.10s on
ubuntu, and a ratio is scale-invariant so a longer trip count cannot close it.
`synth_perf_gate` documents an absent ceiling as a full exemption, which 252 of
the 525 synthetic fixtures already are.
`exception_loop_warmup`'s 6.5 from the previous commit is left alone: the wider
sample puts its window at 4.9-12.0, and run 33693600706 measured it at 4.5x
under the new ceiling, where it had failed at 5.0x under the old one.
No trip count, jit-stats baseline or fixture output changes. pyre/check.py
--check-headers: 527 headers read.
Assisted-by: Claude bench/synth: refit three more ceilings the startup subtraction moved, and retire a fourth
`exception_loop_warmup` was not alone in the position `6aabe927ce1` left it in,
and refitting it alone moved the failure rather than removing it: the same job
then failed `for_iter_conditional_store_bridge`, which is what `gate` and
`jit-gc-resume-gaps` had been failing on all along.
Fitted from 12 CI runs created after that commit -- readings from before it
subtracted a different quantity and are not evidence about these gates. Only
unmarked rows are used. A `?` row carries a granularity buffer worth
EXEC_TIME_FLOOR_S over its baseline, which is what lets it print a ratio far
above its ceiling without failing, so counting one would fit the gate to a
reading that cannot fail it; every one of these fixtures has its widest reading
on such a row, on windows dynasm or ubuntu wasm.
Each ceiling has to cover the widest unmarked reading and derive a floor
(ceiling/6, capped at parity) under the narrowest, which fixes a window:
for_iter_conditional_store_bridge 1.6x-5.1x n=55 window 5.1-9.6 4 -> 7
condexpr_heap_const_merge 2.2x-6.6x n=54 window 6.6-13.2 4.2 -> 9
for_iter_nested_method_inline 0.9x-3.6x n=61 window 3.6-5.4 3.3 -> 4.4
`for_iter_method_branch_inline` loses its ceiling instead. Its unmarked
readings span 0.8x to 4.5x over 60 observations, a factor of 5.6 against a
PERF_GATE_FLOOR_DIVISOR of 6, which leaves the window 4.5-4.8 -- six percent
wide, with under three percent of margin at either end. A bound that narrow
over that many samples reports the runner rather than the code. The spread is
the denominator's: pypy executes this loop in 0.30s on macos and 0.10s on
ubuntu, and a ratio is scale-invariant so a longer trip count cannot close it.
`synth_perf_gate` documents an absent ceiling as a full exemption, which 252 of
the 525 synthetic fixtures already are.
`exception_loop_warmup`'s 6.5 from the previous commit is left alone: the wider
sample puts its window at 4.9-12.0, and run 33693600706 measured it at 4.5x
under the new ceiling, where it had failed at 5.0x under the old one.
No trip count, jit-stats baseline or fixture output changes. pyre/check.py
--check-headers: 527 headers read.
Assisted-by: Claude interp, object: correct five dont_look_inside comments about the boxing fuse
Three of the markers justified themselves with "boxes it through the
non-numeric `malloc_typed` (`fuse_boxing_alloc` fuses only the numeric boxes),
so tracing into it carries the unported `malloc->new` lowering into the
caller". Both halves are false: the fuse has been struct-generic since #1503,
and the `malloc->new` fork is ported.
What actually keeps `w_exception_new_empty_impl` and
`w_dict_view_iterator_new_direction` from lowering is their type word, picked
at runtime (`exc_kind_to_pytype(kind)`,
`dict_view_iterator_type_for_kind(kind, reverse)`). A cluster whose type word
is not a constant address does not lower: the word rides on the allocation or
not at all, a `setfield_gc` whose descr `is_typeptr()` being removed
downstream. Their primary allocations are hand-rolled through
`try_gc_alloc_stable_raw` / `try_gc_alloc_nursery_raw` besides, which are not
`lltype::malloc*` spellings the fuse recognises.
`builtin_code_new_full` is the opposite case and its comment now says so: its
`ob_type` is `&BUILTIN_CODE_TYPE`, a constant, so the cluster would be taken
onto a `NewWithVtable` like any other. The allocation is not what its marker
is for.
`w_module_dict_new` and `w_module_new_aliasing_dict` keep their own claims;
only the stale "unported" is dropped from them.
Comments only.
Assisted-by: Claude bench: re-record four fixtures against 78501667f54
The corpus run at the rebased base moves four fixtures on all three
backends, with identical counters on each, and every one of the four still
prints what CPython 3.14 and PyPy 7.3.23 print.
attribute_error_enrichment bridges_compiled 5 -> 4, guard_failures 1008 -> 905
getattribute_override_no_bind loops_compiled 1 -> 2
property_custom_hook_decline loops_compiled 3 -> 2, guard_failures 4 -> 1
getframe_audit_event guard_failures 22 -> 8968,
fbw_blackhole_adopted_single_frame 5 -> 1,
loops_aborted 5 -> 1, loops_compiled 2 -> 3
`getframe_audit_event` is the one worth reading. Its topology improved --
the loop that used to abort five times now compiles, leaving one abort --
and the guard-failure count is what compiling it costs. `MAJIT_LOG` counts
exactly 8968 `[blackhole-resume]` events, one per failure, all reached from
a bridge through the `rd_numb=38` resume group. The fixture installs its
audit hook from inside the loop at the halfway point precisely so the
quasi-immutable hook list is revoked in flight, and its header already
states that the tail has to deliver one event per remaining iteration;
compiled code has no way to raise the event, so the tail leaves the trace.
Three runs read 8968, so the number is not a sampling artefact. Wall time
is unchanged at 0.02s against pypy's 0.02s and no ratio gate fires.
Assisted-by: Claude jit-trace: dispatch int_is_zero in the int unary record table
`unop_int_record` in the jitcode walker carries `int_neg`, `int_invert`,
`int_same_as` and `int_is_true` but not `int_is_zero`, which `pyjitpl.py`
generates from that same unary list. An opname the table does not name
falls to `DispatchError::UnsupportedOpname`, which aborts the trace part
way through the body being walked.
`_rewrite_equality` folds `int_eq(x, 0)` into `int_is_zero`, so this branch
is the first to put the opname in a body -- 1232 occurrences in the shipped
jitcodes. Against that, `synth/list_append_virtual_payload` answered
`TypeError: 'float' object is not an iterator`, `synth/zero_arg_super_attr`
did not terminate, and `synth/pickle_ctor_args` recorded `loops_compiled=0`
where its committed sidecar records `loops_compiled=2 loops_aborted=0
fbw_blackhole_adopted_*=0`. With the arm in place those three, and
test_heapq / test_random / test_pickle, answer as before.
Add unit tests for `int_is_true` and `int_is_zero` -- `drive_int_unop`
panics on a dispatch error, so both assert the arm exists -- and a selfcheck
fixture over float-element list comprehensions, the shape that reproduces
the wrong answer.
Assisted-by: Claude Latest Branches
0%
-31%
0%
© 2026 CodSpeed Technology