Skip to content

gh-133273: Keep instruction definitions in bytecodes.c and optimizer_bytecodes.c in sync #133320

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

tomasr8
Copy link
Member

@tomasr8 tomasr8 commented May 2, 2025

This implements the currently empty validate_uop.

It requires that instructions in bytecodes.c and optimizer_bytecodes.c:

  • have the same number of inputs and outputs
  • the input and output names match

Should we also validate the type/size?

I needed rename a few variables in bytecodes.c from unused to an actual name, otherwise changes are
kept to optimizer_bytecodes.c. There are some things I'm not sure about, I'll add comments to the relevant lines.

@brandtbucher
Copy link
Member

Thanks!

Personally, I'm not sure that requiring the names to be in sync gains us anything. What's really useful is making sure that the stack effects are the same; if not, it's a serious bug in the optimizer. Making the names match just sort of creates busywork for anyone adding new optimizer cases.

And I think it's totally normal for something that's used in the bytecodes to be unused in the optimizer, and vice-versa. So I'd rather just have a special case for when one is unused (which the code generator can use to make the instruction more efficient), instead of forcing them to be loaded and the warnings to be manually silenced.

I'll wait for others to chime in, though. It's not a huge deal.

@@ -1542,7 +1542,7 @@ dummy_func(
(void)counter;
}

op(_UNPACK_SEQUENCE, (seq -- unused[oparg], top[0])) {
Copy link
Member

Choose a reason for hiding this comment

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

Would it be possible to tell the validator that unused matches anything (both ways)?

So unused in optimizer_bytecodes/bytecodes isn't name-validated.

@Fidget-Spinner
Copy link
Member

Thanks!

Personally, I'm not sure that requiring the names to be in sync gains us anything. What's really useful is making sure that the stack effects are the same; if not, it's a serious bug in the optimizer. Making the names match just sort of creates busywork for anyone adding new optimizer cases.

And I think it's totally normal for something that's used in the bytecodes to be unused in the optimizer, and vice-versa. So I'd rather just have a special case for when one is unused (which the code generator can use to make the instruction more efficient), instead of forcing them to be loaded and the warnings to be manually silenced.

I agree on the unused part (see the comment above), but I think having names matching is useful, if just for the sake of standardization.

@tomasr8 tomasr8 marked this pull request as draft May 3, 2025 08:50
@tomasr8
Copy link
Member Author

tomasr8 commented May 3, 2025

Thanks for the feedback! I updated the PR:

  • Ignore unused when checking uop names
  • Ensure that the uop size matches

Thanks to special-casing unused, I didn't need to modify bytecodes.c at all.

I also added skip news, since this is an internal change.

(I'll wait for the CI to pass and then mark it as ready)

}

op(_CREATE_INIT_FRAME, (self, init, args[oparg] -- init_frame: _Py_UOpsAbstractFrame *)) {
op(_CREATE_INIT_FRAME, (init, self, args[oparg] -- init_frame: _Py_UOpsAbstractFrame *)) {
Copy link
Member Author

Choose a reason for hiding this comment

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

Looks like we found one case where checking the name is useful

@tomasr8 tomasr8 marked this pull request as ready for review May 3, 2025 11:47
@tomasr8 tomasr8 requested a review from Fidget-Spinner May 3, 2025 13:37
@tomasr8 tomasr8 assigned brandtbucher and unassigned brandtbucher May 3, 2025
@tomasr8 tomasr8 requested a review from brandtbucher May 3, 2025 13:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants