gh-139109: JIT _EXIT_TRACE to ENTER_EXECUTOR rather than _DEOPT

[Fidget-Spinner]

This was responsible for the pretty big perf regression in the final benchmarks over the old JIT. It got missed in the flurry of commits and reviews at the end.

• Issue: Trace recording JIT #139109

[efimov-mikhail]

Could you please explain, why this test checks _DEOPT vs _EXIT_TRACE pair?
On my machine it passes both on this PR and on main branch.
Using option --enable-experimental-jit=interpreter or --enable-experimental-jit=yes also doesn't matter.

[Fidget-Spinner]

Hmmm it shouldn't pass on main. Let me strengthen the test.

[efimov-mikhail]

This version of test fails on main with --enable-experimental-jit=interpreter or with --enable-experimental-jit=yes as expected.

[efimov-mikhail]

Also, I've noticed related warning:

Python/optimizer.c: Infunction ‘_PyJit_translate_single_bytecode_to_trace’:
Python/optimizer.c:600:11: warning: operandof ‘?:’ changessignednessfrom ‘int’ to ‘unsigned int’ duetounsignednessofotheroperand [-Wsign-compare]
600 | ? (int)(target_instr-_Py_INTERPRETER_TRAMPOLINE_INSTRUCTIONS_PTR)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Fidget-Spinner]

I'm going to merge this as it's a minor but important fix and I have an approval. Sorry Mark if you want to review it. We can make any further changes in your PR that comes with the switch-case for trace recording.

[efimov-mikhail]

JFTR, I don't know much about the perfomance implications of this PR.
But I'm sure that it's a clean fix with a correct test.

[Fidget-Spinner]

Well, I don't know the exact perf implications either. However, the implication is the following:

1. Currently, when we hit another ENTER_EXECUTOR (ie another executor is seen), we end with _DEOPT.
2. _DEOPT goes back to the interpreter, and does not link executors.

Meanwhile, _EXIT_TRACE links executors. So if we see an ENTER_EXECUTOR and end with an _EXIT_TRACE, we end up linking from the first executor to the executor at the exit.

For Jitted code, the benefits of staying in jitted code without going from jit -> interpreter -> back to jit is enormous. It's one function call with lots of register moves.

[efimov-mikhail]

Yes, I understand the purpose of this change. Meanwhile, thanks for the detailed clarification.