How do we know that the values array is still valid at this point?

There's a case that we are not handling correctly here: if, after loading value_ptr, another thread invalidates the inline values, modifies an attribute, and reallocates another object at the same memory address as the previous attribute, we can incorrectly return a value that wasn't the attribute at that offset.

We need to either:

• Re-check _PyObject_InlineValues(owner_o)->valid at the end of this handler and clean-up and deopt if it's not still true.
• Set the contents of the inlines values array to NULL when we mark it as invalid so that the _Py_TryIncrefCompareStackRef handles this case and correctly deopts.

I think the second options is probably simpler to implement and more efficient given that _LOAD_ATTR_INSTANCE_VALUE is common and invalidating inline values is relatively rare.

Invalidating inline values might not be that rare.
I suggest gathering some stats before deciding how to handle this.

From
https://github.com/faster-cpython/benchmarking-public/blob/main/results/bm-20250104-3.14.0a3%2B-0cafa97/bm-20250104-azure-x86_64-python-0cafa97932c6574734bb-3.14.0a3%2B-0cafa97-pystats.md:

LOAD_ATTR_INSTANCE_VALUE: 4,922,474,147
Materialize dict (on request) | 4,444,396 | 2.4%
Materialize dict (new key) | 476,375 | 0.3%
Materialize dict (too big) | 4,884 | 0.0%
Materialize dict (str subclass) | 0 | 0.0%

So, LOAD_ATTR_INSTANCE_VALUE is somewhere between 1,000x-10,000x more frequent than invalidating inline values. (Invalidating inline values requires first materializing the dictionary, but materializing the dictionary doesn't always invalidate the inline values).

What does _Py_TryIncrefCompareStackRef do?
Function names need to be self explanatory. The result of this function does not depend on a comparison, but on whether something has been modified. Maybe _Py_TryIncrefIfPointersConsistentStackRef as it only works if the `PyObject ** and PyObject *pointers are consistent.

I know that _Py_TryIncrefCompareStackRef was not introduced in this PR, but it is critical to the understanding of this code.

It is an atomic compare-and-incref function, similar to how _Py_atomic_compare_exchange is an atomic compare-and-swap function. If the comparison succeeds, the value is incref'd and 1 is returned. 0 is returned on failure.

"Compare" is a more appropriate term than "consistent" here.

I still think "Compare" is misleading. The name should say what the function does, not how it does it.