-
-
Notifications
You must be signed in to change notification settings - Fork 32k
(Auto-?) generate bottom checks in optimizer_cases.c.h #116088
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
interpreter-core
(Objects, Python, Grammar, and Parser dirs)
Comments
There are current 8 calls to |
gvanrossum
added a commit
that referenced
this issue
Feb 29, 2024
This changes the `sym_set_...()` functions to return a `bool` which is `false` when the symbol is `bottom` after the operation. All calls to such functions now check this result and go to `hit_bottom`, a special error label that prints a different message and then reports that it wasn't able to optimize the trace. No executor will be produced in this case.
woodruffw
pushed a commit
to woodruffw-forks/cpython
that referenced
this issue
Mar 4, 2024
…ython#116089) This changes the `sym_set_...()` functions to return a `bool` which is `false` when the symbol is `bottom` after the operation. All calls to such functions now check this result and go to `hit_bottom`, a special error label that prints a different message and then reports that it wasn't able to optimize the trace. No executor will be produced in this case.
adorilson
pushed a commit
to adorilson/cpython
that referenced
this issue
Mar 25, 2024
…ython#116089) This changes the `sym_set_...()` functions to return a `bool` which is `false` when the symbol is `bottom` after the operation. All calls to such functions now check this result and go to `hit_bottom`, a special error label that prints a different message and then reports that it wasn't able to optimize the trace. No executor will be produced in this case.
diegorusso
pushed a commit
to diegorusso/cpython
that referenced
this issue
Apr 17, 2024
…ython#116089) This changes the `sym_set_...()` functions to return a `bool` which is `false` when the symbol is `bottom` after the operation. All calls to such functions now check this result and go to `hit_bottom`, a special error label that prints a different message and then reports that it wasn't able to optimize the trace. No executor will be produced in this case.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If the abstract interpreter ever pushes
bottom
(i.e., a contradition) to the stack, it might as well stop -- this indicates we're looking at unreachable code (e.g., after a deopt that always deopts, or a branch that always branches).My original idea was to tweak the code generator to auto-generate such checks for the output stack effects (hand-waving a bit around array outputs, which are special anyways). But when I implemented that, I quickly found that most such pushes are freshly created symbols (e.g.
sym_new_const()
orsym_new_undefined()
) that we already know cannot bebottom
.Also, there's a category of stack writes that evades easy detection, e.g. when
_GUARD_BOTH_INT
callssym_set_type(left, &PyLong_Type)
(and ditto forright
), this is part of an opcode whose input and output stack effects are identical, and for such opcodes, the push operation is actually a write (without changing the stack pointer) that is generated on a different code path in the generator.So no I'm considering to just hand-write bottom checks where they seem relevant. Perhaps we can change the
sym_set_...()
functions to return abool
result indicating whether they produced abottom
value, and change the (hand-written) code that calls these to emit something likewhere
hit_bottom
is a new error label that prints a different debug message.I'm still weighing my options though...
Linked PRs
The text was updated successfully, but these errors were encountered: