In the specializing adatpive interpreter, DEOPT_IFs and EXIT_IFs are synonymous, so we have historically been quite haphazard about which to use.
In the JIT, however, there is an important difference: a DEOPT_IF drops execution back into the interpreter unconditionally, whereas an EXIT_IF causes a side-exit which can warm up and also be jitted.
In some cases, like in a CALL or a SEND, the DEOPT_IF prevents the code from being ever being jitted after the exit. See #145047 for an explanation.
There are currently 109 DEOPT_IFs in bytecodes.c. Many of those should be EXIT_IFs.
Specifically, DEOPT_IFs should be converted to EXIT_IFs if they are:
- In a guard (e.g.
_GUARD_CALLABLE_STR_1)
- In the guard part of a more complex uop (e.g.
_CHECK_AND_ALLOCATE_OBJECT)
DEOPT_IFs should be left alone if any of these are true:
- It is in teir1-only code
- It is an error, and we are exiting to let the interpeter handle the error
- The interpreter needs to handle something before continuing in jitted code (e.g the eval breaker)
- An optimization is no longer valid and re-specialization/jitting needs to happen
Linked PRs
In the specializing adatpive interpreter,
DEOPT_IFs andEXIT_IFs are synonymous, so we have historically been quite haphazard about which to use.In the JIT, however, there is an important difference: a
DEOPT_IFdrops execution back into the interpreter unconditionally, whereas anEXIT_IFcauses a side-exit which can warm up and also be jitted.In some cases, like in a
CALLor aSEND, theDEOPT_IFprevents the code from being ever being jitted after the exit. See #145047 for an explanation.There are currently 109
DEOPT_IFs in bytecodes.c. Many of those should beEXIT_IFs.Specifically,
DEOPT_IFs should be converted toEXIT_IFs if they are:_GUARD_CALLABLE_STR_1)_CHECK_AND_ALLOCATE_OBJECT)DEOPT_IFs should be left alone if any of these are true:Linked PRs