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