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

GH-99298: Don't perform jumps before error handling #99299

Merged
merged 2 commits into from Nov 10, 2022

Conversation

brandtbucher
Copy link
Member

@brandtbucher brandtbucher commented Nov 9, 2022

My next steps:

  • This will need a manual backport to 3.11 (3.10 seems unaffected).
  • For 3.12, _Py_Specialize_LoadAttr and _Py_Specialize_StoreAttr don't actually need to handle errors (we can just fail to specialize "unready" types, which are probably super rare in practice).

@brandtbucher brandtbucher added type-bug An unexpected behavior, bug, or error interpreter-core Interpreter core (Objects, Python, Grammar, and Parser dirs) labels Nov 9, 2022
@brandtbucher brandtbucher requested a review from markshannon Nov 9, 2022
@brandtbucher brandtbucher self-assigned this Nov 9, 2022
Copy link
Member

@markshannon markshannon left a comment

LGTM. One minor issue about the error handling.

@@ -1152,6 +1152,8 @@ dummy_func(
PyObject *name = GETITEM(names, oparg);
next_instr--;
if (_Py_Specialize_StoreAttr(owner, next_instr, name)) {
// "undo" the rewind so end up in the correct handler:
next_instr++;
Copy link
Member

@markshannon markshannon Nov 10, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding any code to a conditional block with just a goto adds extra branches.
It's not so important for these slower instructions, but its best avoided in general.

What we generally do is if (cond) goto fixup_error; where fixup_error does the necessary fix before jumping to error:. The C compiler will probably do this for us, but I think it best to be explicit.

Copy link
Member Author

@brandtbucher brandtbucher Nov 10, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, see my comment at the top of this PR. _Py_Specialize_StoreAttr and _Py_Specialize_LoadAttr don't really need error handling at all, so the next thing I'm going to do it make them return void like the others in 3.12. Then we don't need the branch at all. :)

I'm hesitant to add additional labels and gotos to the 3.11 backport, especially since this is pretty cold code. Let me know if you think I should, though.

Copy link
Member

@markshannon markshannon Nov 10, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, leave this for this PR.

Maybe make a PR for 3.12 that removes the branch entirely?

@markshannon markshannon self-requested a review Nov 10, 2022
@brandtbucher brandtbucher merged commit 00ee6d5 into python:main Nov 10, 2022
15 checks passed
gvanrossum pushed a commit to gvanrossum/cpython that referenced this pull request Nov 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
interpreter-core Interpreter core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants