Specialization of some instructions does not conform to PEP 659, and prevents PEP 669

[markshannon]

As written, PEP 659 says that individual specializations are restricted to a single instruction.
PEP 669 relies on this, as it also wants to replace instructions at runtime, and it would break if specialization occurs across multiple instructions.

Currently there are a two places where we break this design by specializing pairs of instructions together:

• COMPARE_OP POP_JUMP_IF_ pairs are specialized together
• FOR_ITER STORE_FAST are specialized together

The second will go away with the register VM, and doesn't seem to be an issue in practice.
It is the COMPARE_OP POP_JUMP_IF_ specialization that is problematic, as PEP 669 wants to instrument branches.
Instrumenting the POP_JUMP_IF_ doesn't work if the COMPARE_OP specialization jumps over it.

The solution is to replace the COMPARE_OP POP_JUMP_IF_ pair with a single COMPARE_AND_BRANCH instruction that can be specialized or instrumented atomically.

Linked PRs

• GH-100982: Add COMPARE_AND_BRANCH instruction #100983
• GH-100982: Restrict FOR_ITER_RANGE to a single instruction to allow instrumentation. #101985
• GH-100982: Break up COMPARE_AND_BRANCH #102801

[markshannon]

Superinstructions are also a problem for PEP 669, but are simpler to handle, and will also go away with the register VM.

[brandtbucher]

BINARY_OP_INPLACE_ADD_UNICODE and CALL_NO_KW_LIST_APPEND are two more examples of "adaptive superinstructions".

Like FOR_ITER, though, they don't cross a branch and will probably disappear when we get a register VM.

[markshannon]

https://github.com/python/cpython/pull/100983[)](https://github.com/python/cpython/commit/7b14c2ef194b6eed79670aa9d7e29ab8e2256a56) fixed the COMPARE_OP issue, so I'm retitling this issue.

[markshannon]

Although BINARY_OP_INPLACE_ADD_UNICODE and CALL_NO_KW_LIST_APPEND don't cross boundaries they may cross lines which interferes with instrumentation for LINE events.

[markshannon]

The instruction that is skipped in CALL_NO_KW_LIST_APPEND is always a POP_TOP.
We can fix this by making sure that the POP_TOP following a call has no location. It probably should anyway.
The compiler already gives POP_TOP NO_LOCATION so nothing to do here

BINARY_OP_INPLACE_ADD_UNICODE is still a problem. It is rare, so the extra cost of de-specializing it during instrumentation and preventing that specialization if instrumentation is present would probably be OK.

Note:
This is only an issue for instrumentation of LINE events. INSTRUCTION events prevent all specialization, so there cannot be a conflict.

[markshannon]

An alternative to fixing BINARY_OP_INPLACE_ADD_UNICODE is to restore the old behavior of BINARY_ADD to special case adding strings, and make sure that BINARY_OP specialization is so good that the performance of plain BINARY_ADD is irrelevant.

[markshannon]

Which leaves FOR_ITER_RANGE. I'm hoping that improvements to freelists and integer representation will make the cost of creating the temporary int tolerable.