GeezerVison

It doesn't seem like this comment applies to the tuple specialization. Can you delete it if not?

Done.

Can you expand a little bit on why this doesn't make sense? It'd be nice to keep the structure of the ops the same between the two builds.

Done.

Why does this need the HAS_ESCAPES_FLAG? How does it escape?

The mechanism for fetching an item from a shared list includes calling _Py_TryIncrefCompare, which has a path which DECREFs.

Which path? I'm confused as why an incref would need to decref.

When the reference is removed from the array that backs the list between the time it's retrieved and it's returned.

Added in #114512.

I don't see how that works. What happens if *src is modified after op != _Py_atomic_load_ptr(src) but before the function returns?

Regardless, we want to keep FOR_ITER_LIST non-escaping in the default build.

@colesbury do you remember why lists use _Py_TryXGetRef (in list_get_item_ref) or why it matters that the src ptr still refers to the same item? Can the object be invalid in some way that still requires us to DECREF it?

There are two hazards that _Py_TryXGetRef handles:

1. The object op may be deallocated between the initial load and the incref. The try-incref, in cooperation with the allocator, handles this case. It returns zero if op has zero refcount.
2. The memory block for op may be deallocated and reallocated for a different object in between the initial load and incref. In that case the try-incref succeeds, but the subsequent check fails and we need to decref op.

It does not matter if *src is modified after op != _Py_atomic_load_ptr(src). op will still be a valid reference to an object that was the next element in the list at some point during the operation. It's always been possible for the list to be concurrently modified between the execution of FOR_ITER and subsequent code that uses the result.

See https://peps.python.org/pep-0703/#optimistically-avoiding-locking

Regardless, we want to keep FOR_ITER_LIST non-escaping in the default build

Is there any performance reason to do so?

Regardless, we want to keep FOR_ITER_LIST non-escaping in the default build

Is there any performance reason to do so?

Just to follow up: this does make JIT code slightly worse for traces covering for loops over lists. Since the _ITER_NEXT_LIST at the top of the loop is now escaping, this will add a new _CHECK_VALIDITY uop to the start of each loop body where none exists currently.

Consider this loop:

def f():
    x = 0
    for i in list(range(10_000)):
        x += i

This change increases the number of validity checks per loop from 2 to 3. Before:

_MAKE_WARM
_SET_IP
_CHECK_PERIODIC
_CHECK_VALIDITY <------------- OLD
_ITER_CHECK_LIST
_GUARD_NOT_EXHAUSTED_LIST
_ITER_NEXT_LIST
_SET_IP
_STORE_FAST_1
_CHECK_VALIDITY <------------- OLD
_LOAD_FAST_0
_LOAD_FAST_1
_GUARD_BOTH_INT
_BINARY_OP_ADD_INT
_SET_IP
_STORE_FAST_0
_JUMP_TO_TOP

After:

_MAKE_WARM
_SET_IP
_CHECK_PERIODIC
_CHECK_VALIDITY <------------- OLD
_ITER_CHECK_LIST
_GUARD_NOT_EXHAUSTED_LIST
_ITER_NEXT_LIST
_CHECK_VALIDITY_AND_SET_IP <-- NEW
_STORE_FAST_1
_CHECK_VALIDITY <------------- OLD
_LOAD_FAST_0
_LOAD_FAST_1
_GUARD_BOTH_INT
_BINARY_OP_ADD_INT
_SET_IP
_STORE_FAST_0
_JUMP_TO_TOP

Just to clarify:
FOR_ITER_LIST is escaping because _PyList_GetItemRefNoLock is escaping, and _PyList_GetItemRefNoLock is escaping because _Py_TryIncrefCompareStackRef is escaping.

Either we need to find an alternative approach or make _Py_TryIncrefCompareStackRef non-escaping.

Just to clarify:
FOR_ITER_LIST is escaping because _PyList_GetItemRefNoLock is escaping, and _PyList_GetItemRefNoLock is escaping because _Py_TryIncrefCompareStackRef is escaping.

Either we need to find an alternative approach or make _Py_TryIncrefCompareStackRef non-escaping.