Frame pointer (and any per-function features) builds of tail calling interpreter slower than expected

Bug report

Bug description:

When building with the normal interpreter (computed goto), the impact of frame pointers should only be around 2% geomean max.

However, it seems the impact on the tail calling interpreter is higher. This is likely because each bytecode handler on the tail calling interpreter is now a function, which means they each have a frame pointer prologue and epilogue.

There is a fix on Clang 21 and higher (though I don't know if GCC 16 has it): omit the frame pointer, but reserve it so it doesn't get clobbered only for the bytecode handlers, leave the rest building with frame pointers. The flags are "-fomit-frame-pointer -momit-leaf-frame-pointer -mreserve-frame-pointer-reg". The key observation is that since we tail call, we only need the first entry into a tail calling handler to have the frame pointer prologue (ie LABEL(start_frame) needs the prologue), but all other tail calling function pointers do not. This practically eliminates the entire prologue/epilogue overhead for the interpreter, while keeping register allocation good and not clobbering frame pointers. Unfortunately, clang does seem not have custom per-function attributes for this option, so we have to move the non-starter bytecode handlers to their own compilation unit (ie, move them to their own C file).

This seems to affect anything with per-function overhead as well, such as CET/BTI changes. We can fix those incrementally, as the approacha re the same.

Here are some geometric mean results on Sam's fastmark (pyperformance subset) from my laptop (i7-12700H x86-64) with clang 22:

• Baseline (FP on, tail calling interpreter): 0% slowdown
• FP off, tail calling interpreter: 2.7% speedup
• FP on, tail calling interpreter, reserve register patch (meowl + garbage + oiia): 2.5% speedup

TLDR: WIth this patch, the tail calling interpreter's overhead for frame pointer enabling drops from 2.7% to just 0.2%!!!! Frame pointers are practically free on the tail calling interpreter!!! Meanwhile, computed goto interpreter has a 1.5% hit (the i7-12700h machine is mine from PEP 831)

@pablogsal @markshannon @stratakis

CPython versions tested on:

CPython main branch

Operating systems tested on:

No response

Start by inspecting the tail-calling interpreter around the LABEL(start_frame) entry point and the build configuration for its bytecode handlers. Run the linked fastmark benchmark with Clang and compare the reported frame-pointer overhead; done means the tail-calling interpreter retains frame pointers without the handler prologue/epilogue slowdown described here.