The contract of_PyExecutorObject currently is that it executes zero or more bytecode instructions.
We should change that so that it must execute at least one instruction.
The reason for this change is so that we can useENTER_EXECUTOR anywhere, and that we will need to replace arbitrary instructions withENTER_EXECUTOR (see below for why)

If a_PyExecutorObject executes zero instructions, thenENTER_EXECUTOR is responsible for executing the original instruction.

If it executes one or more instructions the behavior of the first instruction is handled by the_PyExecutorObject soENTER_EXECUTOR is just a simple, and fast, (tail) call.

We also want to change the signature of theexecute function pointer to take_PyExecutorObject ** instead of_PyExecutorObject *.
Seefaster-cpython/ideas#621 for details.

We might as well make both changes at once.
I think our only "real" optimizer already executes at least three instructions, so it should be a fairly easy change.

Why do we need insert executors at arbitrary instructions?

Consider a nested if with at least two balanced hot paths, and at least one cold path.
At the join point, we want both paths to continue in optimized code, but as neither represents more than 50% of the flow, they will likely stop at the join point. Ideally, they will both jump into the same, following optimized code. But in order to find it, it needs to be attached to the tier 1 instructions usingENTER_EXECUTOR and that join point could be an arbitrary instruction, likely aLOAD_FAST orLOAD_GLOBAL.

Note that this makes life harder for the optimizer, as it cannot simply exit the optimized code if a guard fails in the first instruction. It is obliged to fully execute that instruction.

Other optimizers might also want to overwrite instructions withENTER_EXECUTOR; PyTorch Dynamo, for example.

@gvanrossum

Linked PRs

• GH-108866: Change optimizer API and contract #109144
• GH-108866: Guarantee forward progress in executors. #113006