Skip to content
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

(Auto-?) generate bottom checks in optimizer_cases.c.h #116088

Closed
Tracked by #115419
gvanrossum opened this issue Feb 29, 2024 · 1 comment
Closed
Tracked by #115419

(Auto-?) generate bottom checks in optimizer_cases.c.h #116088

gvanrossum opened this issue Feb 29, 2024 · 1 comment
Assignees
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs)

Comments

@gvanrossum
Copy link
Member

gvanrossum commented Feb 29, 2024

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() or sym_new_undefined()) that we already know cannot be bottom.

Also, there's a category of stack writes that evades easy detection, e.g. when _GUARD_BOTH_INT calls sym_set_type(left, &PyLong_Type) (and ditto for right), 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 a bool result indicating whether they produced a bottom value, and change the (hand-written) code that calls these to emit something like

if (sym_set_null(sym)) {
    goto hit_bottom;
}

where hit_bottom is a new error label that prints a different debug message.

I'm still weighing my options though...

Linked PRs

@gvanrossum gvanrossum added the interpreter-core (Objects, Python, Grammar, and Parser dirs) label Feb 29, 2024
@gvanrossum gvanrossum self-assigned this Feb 29, 2024
@gvanrossum
Copy link
Member Author

There are current 8 calls to sym_set_type() and one call to sym_set_null() in optimizer_bytecodes.c, and none to the other sym_set_...() functions. I think I'll go low-tech.

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
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs)
Projects
None yet
Development

No branches or pull requests

1 participant