This PR finishes specialization forLOAD_ATTR in the free-threaded build by adding support for class and instance receivers.

The bulk of it is dedicated to making the specialized instructions and the specialization logic thread-safe. This consists of using atomics / locks in the appropriate places, avoiding races in specialization related to reloading versions, and ensuring that the objects stored in inline caches remain valid when accessed (by only storing deferred objects). See the section on "Thread Safety" below for more details.

Additionally, making this work required a few unrelated changes to fix existing bugs or work around differences between the two builds that results from only storing deferred values (which causes in specialization failures in the free-threaded build when a value that would be stored in the cache is not deferred):

• Fixed a bug in the cases generator where it wasn't treating macro tokens as terminators when searching for the assignment target of an expression involvingPyStackRef_FromPyObjectNew.
• Refactoredtest_descr.MiscTests.test_type_lookup_mro_reference to work when specialization fails (and also be a behavorial test).
• Temporarily skiptest_capi.test_type.TypeTests.test_freeze_meta when running refleaks tests on free-threaded builds. Specialization failure triggers an existing bug.

Single-threaded Performance

• Performance is improved by ~12% on free-threaded builds.
• Performance is ~neutral on default builds. (Technically the benchmark runner reports a 0.2% improvement, but that looks like noise to me.)

We're leaving a bit of perf on the table by only storing deferred objects: we can't specialize attribute lookups that resolve to class attributes (e.g. counters, settings). I haven't measured how much perf we're giving up, but I'd like to address that in a separate PR.

Scalability

Theobject_cfunction andpymethod benchmarks are improved (1.4x slower -> 14.3x faster, 1.8x slower -> 13.0x faster, respectively). Other benchmarks appear unchanged.

I would expect thatcmodule_function would also improve, but it looks like the benchmark is bottlenecked on increfing theint.__floor__ method that is returned from the call to_PyObject_LookupSpecial inmath_floor (the incref happens in_PyType_LookupRef, which is called byPyObject_LookupSpecial):

Raw numbers:

Running benchmarks with 28 threads                   Merge-base    This PRobject_cfunction    1.4x slower  14.3x fastercmodule_function    1.7x slower   1.7x slowermult_constant      12.8x faster  13.6x fastergenerator          11.5x faster  12.2x fasterpymethod            1.8x slower  13.4x fasterpyfunction         12.2x faster  13.0x fastermodule_function    14.5x faster  14.8x fasterload_string_const  13.0x faster  13.2x fasterload_tuple_const   12.7x faster  14.1x fastercreate_pyobject    12.8x faster  13.5x fastercreate_closure     13.9x faster  14.8x fastercreate_dict        10.5x faster  13.3x fasterthread_local_read   3.9x slower   4.0x slower

Thread Safety

Thread safety of specialized instructions is addressed in a few different ways:

• Use atomics where needed.
• Lock the instance dictionary in_LOAD_ATTR_WITH_HINT.
• Only store deferred objects in the inline cache. All uops that retrieve objects from the cache are preceded by type version guards, which ensure that the (deferred) value retrieved from the cache is valid. The type version will be mutated before destroying the reference in the type. If the type held the last reference, then GC will need to run in order to reclaim the object. GC requires stopping the world, so if GC reclaims the object then we will see the new type version and the guard will fail.

Thread safety of specialization is addressed using similar techniques:

• Atomics / locking is used to access shared state.
• Specialization code is refactored to read versions at the start of specialization and store the same version in caches (as opposed to rereading the version). This ensures that the specialization is consistent with the version by avoiding races where the type or shared keys dictionary changes after we've queried it.

Stats

Following theinstructions in the comment precedingspecialize_attr_loadclassattr, I collected stats for the default build for both this PR and its merge base using./python -m test_typing test_re test_dis test_zlib and compared them usingTools/scripts/summarize_stats.py. The results forLOAD_ATTR are nearly identical and are consistent with results from comparing the merge base against itself:

• Comparison
• Raw stats for merge base
• Raw stats for PR

• Issue:Make the specializing interpreter thread-safe in--disable-gil builds #115999