GeezerVison

Edit: I might be wrong on the following, so please ignore the rest.

Really sorry I just realised this optimization may not be sound:

The builtin call specializations only check for that the builtin tp flags match, I don't think they check for tp_version_tag and such. So we can have a method that changes its tp_slots under our feet.

Sorry for taking up your time!

The rewriting that we discussed might still pay off though (rewriting {}.get() to a custom uop for example).

That should also be sound, provided we have the correct guards.

I think this is safe: let me explain why:

1. PyMethodDescrObjects are immutable (as Kumar pointed out).
2. type version tags are unique (unless they overflow, which is pretty unlikely as they have limits now).
3. _GUARD_TYPE_VERSION and the type watcher later implies the type and thus method transitively later on.
   TLDR: This is safe on the invariant that LOAD_ATTR guards itself, and all known information is sourced from there to optimize the calls.

Microbenchmark results of calling bunch of methods on each type:

Btw, could you please update your comment above with the final benchmark results on the current commit?

The numbers are very similar and within margin of error so keeping the existing result.

Seems like a slight win on macOS, and a slight loss on x86-64 https://github.com/facebookexperimental/free-threading-benchmarking/tree/main/results/bm-20260403-3.15.0a7+-e4a2fff-JIT

Seems like a slight win on macOS, and a slight loss on x86-64 https://github.com/facebookexperimental/free-threading-benchmarking/tree/main/results/bm-20260403-3.15.0a7+-e4a2fff-JIT

I think the benchmark runner is too noisy, for example the gc_traversal benchmark is 8% slower on linux but should be unaffected by this PR.