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 theHAS_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 afterop != _Py_atomic_load_ptr(src) but before the function returns?

Regardless, we want to keepFOR_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 objectop may be deallocated between the initial load and the incref. The try-incref, in cooperation with the allocator, handles this case. It returns zero ifop has zero refcount.
2. The memory block forop may be deallocatedand 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 decrefop.

It does not matter if*src is modified afterop != _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 ofFOR_ITER and subsequent code that uses the result.

Seehttps://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 codeslightly worse for traces coveringfor 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:

deff():x=0foriinlist(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.