GH-120024: Remove CHECK_EVAL_BREAKER macro.
#122968
Conversation
… for escape analysis
| if (_Py_HandlePending(tstate) != 0) { | ||
| GOTO_ERROR(error); \ | ||
| } | ||
| } |
There was a problem hiding this comment.
Can this be implemented as a macro that reuses _CHECK_PERIODIC? Like "if condition is false, exit, then do _CHECK_PERIODIC"?
There was a problem hiding this comment.
Removing the macro is the point of this PR. Macros are opaque to the code generator, so we need to special case them (which is OK for something very common like Py_DECREF). Avoiding the special case simplifies the code generator considerably.
It is the call to _Py_HandlePending that escapes, not the whole of _CHECK_PERIODIC and we want the code generator to know that.
There was a problem hiding this comment.
I meant a macro instruction of the DSL.
There was a problem hiding this comment.
Ah, I see.
No it can't, as macros can only be composed in a linear sequence. We need branching here, not deoptimization.
EXIT_IF and DEOPT_IF only make sense in specialized instructions.
* Factor some instructions into micro-ops to isolate CHECK_EVAL_BREAKER for escape analysis * Eliminate CHECK_EVAL_BREAKER macro
Removing the
CHECK_EVAL_BREAKERby moving into its own pair of micro-ops allows us to remove a lot of special case code that impairs getting escaping calls.The
CHECK_EVAL_BREAKERmacro is a conditional expression containing an escaping call and error handling. By removing the macro, the code generator can see the parts and analyze them correctly.This PR is probably best reviewed commit by commit.