gh-131798: Add tier-2 list specialization for STORE_SLICE

[eendebakpt]

The JIT currently dispatches STORE_SLICE (container[start:stop] = value) through PyObject_SetItem even when the trace has proven the container is an exact list. Adding a tier-2 specialization _STORE_SLICE_LIST skips the slice-object allocation and the generic lookup.

The optimizer rewrites _STORE_SLICE → _STORE_SLICE_LIST only when the container's type is statically known, so non-list callers and tier-1 are unaffected. A second commit for bytearray was added but reverted.

Benchmark results on pyperformance fannkuch (tier-2 / JIT enabled):

main (252 ± 3 ms) -> PR (223 ± 2 ms): 1.13x faster

• Issue: Better uop coverage in the JIT optimizer #131798

[read-the-docs-community]

Documentation build overview

📚 cpython-previews | 🛠️ Build #32814396 | 📁 Comparing 0bc13a1 against main (970b043)

🔍 Preview build

1 file changed

±whatsnew/changelog.html

[markshannon]

One question, otherwise looks good.

It would be good to optimize constant slices, but that would need a change to the bytecode compiler. For another PR.

[eendebakpt]

One question, otherwise looks good.

It would be good to optimize constant slices, but that would need a change to the bytecode compiler. For another PR.

Ah yes. So the mechanism is: for x[1:2] = ... there is a constant slice. The compiler optimizes this to LOAD_CONST and STORE_SUBSCR (which is not specialized), which means we will never get to the specialized STORE_SLICE introduced in this PR.

We could:

1. Skip the optimization now that STORE_SLICE has more specializations (compiler change).
2. Specialize STORE_SUBSCR for lists (and more types?)

I am leaning towards the second option (initially only in tier2 to avoid adding a tier1 opcode).

Update: a branch with STORE_SUBSCR specialized is main...eendebakpt:cpython:gh-131798-store-subscr-list-slice, but there is hardly any performance gain.