Allow storing the instruction offset as an alternative to the instruction pointer in the frame.

Feature or enhancement

Proposal:

The CPython JIT compiler, and other compilers like CinderX, need to keep the current frame's instruction pointer up-to-date so that code introspecting the frame can determine the location that is currently being executed.

Before 3.11, the instruction offset was stored in the frame and this is still the value that Python code sees, frame.f_lasti, but it is inefficient to repeatedly calculate an offset in the interpreter, so internally we store the pointer and calculate the offset lazily when needed.

A JIT, however, does not want to maintain an instruction pointer, as it has to store the pointer every time that a call can escape. Instead or storing a 64 bit pointer, it is more efficient to store a 16 bit offset.
Also, with free-threading, it is impossible for the JIT to store a pointer, as it depends on the thread local bytecode.

Given that the interpreter wants to store pointers, and the JIT needs offsets, we can either:

1. Use offsets everywhere
2. Use a mix of offsets and pointers

(1) would slow down the interpreter significantly, so is undesirable
(2) gets us the best of both, in terms of performance, but is a bit more complex.

I think option 2, is the best.

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Start by tracing CPython's frame representation and the handling of the instruction offset exposed as frame.f_lasti, then review how the interpreter currently maintains its instruction pointer. The change is done when JITs can maintain an offset while the interpreter can continue using pointers, including under free-threading, without losing the location visible to frame introspection.