GH-108866: Change optimizer API and contract

[markshannon]

Partial implementation of #108866

• Changes the return type of the execute function from _PyInterpreterFrame * to _Py_CODEUNIT *, returning the next instruction to execute
• The execute function always executes at least one instruction.

Since the uop and optimizer and executor start at the top of the loop, starting at the JUMP_BACKWARD means that they always execute one or more instructions.
ENTER_EXECUTOR is more efficient as it doesn't need to worry about edge cases like executing no instructions or handling INSTRUMENTED_LINE.

• Issue: We need to change the contract and interface of _PyExecutorObject and _PyOptimizerObject #108866

[gvanrossum]

The more I think about this, the more I think that the problem with signature of the executor is that it has too many return values:

• An error indicator
• The frame where the error (or exit) occurred
• The instruction pointer where it occurred
• The stack pointer at that time

Both the frame and the instruction pointer are needed to continue execution and also for error handling, and both can differ from the value before the executor runs. Same for the stack pointer (though we always sync that through the frame object).

Things would be neater if these were all explicit and we didn't have to recover one or the other through tstate->current_frame.

The optimizer inherits this awkwardness because it promises to also run the executor. (And why is that? It seems to make things more complicated, and it means the opcode isn't replaced until after that first run -- won't that confuse other threads?)

The requirement to include the JUMP_BACKWARD instruction in the input to the optimizer causes a bunch of extra work which I'm also not keen on. And, despite what I said in in gh-108866, I actually still don't completely understand why we need this.

In any case maybe we need to split the two changes.

[gvanrossum]

Clever. I'd add assert(src->op.code == EXTENDED_ARG).

[brandtbucher]

I don't think this assert is correct, since it could be an INSTRUMENTED_LINE or something. Ditto for the matching assert in _PyOptimizer_BackEdge.

[gvanrossum]

Ouch. Can instrumentation really overwrite EXTENDED_ARG? @markshannon

[markshannon]

The frame pointer, instruction pointer and stack pointer are all part of the VM state.
We either need to store them in memory, or pass them as an argument/return value when calling or returning from a C function (or jitted code).

The only reason we passed these values as arguments or return value was for efficiency. It reduces the number of memory accesses at the point of transfer. If it turns out that most callees don't need them, we can just remove the parameter from the API.

The difference with this PR is that the return value is meaningful, not just a cached value. The next_instr cannot be derived from the prev_instr stored on the frame. If the last instruction was a jump then next_instr != prev_instr + 1.

Things would be neater if these were all explicit and we didn't have to recover one or the other through tstate->current_frame.

tstate->current_frame is the current frame and holds the previous instruction and stack pointers.
Unless we are passing values in registers for performance, we don't want to make copies that could get out of sync.

[gvanrossum]

Thanks for the changes.

I believe we decided offline to hold off on this until Brandt has had an opportunity to change _PyOptimizer_BackEdge not to call the executor, and to modify JUMP_BACKWARD instead to "deoptimize" to ENTER_EXECUTOR. (Or to find out that there was a reason why things are the way they are.)

[markshannon]

This is now obsolete