-
-
Notifications
You must be signed in to change notification settings - Fork 32.2k
bpo-45636: BINARY_OP
(third time's the charm)
#29482
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this approach. Performance is acceptable and should improve with specialization.
🤖 New build scheduled with the buildbot fleet by @markshannon for commit 490b8da 🤖 If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again. |
👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome work!
🤖 New build scheduled with the buildbot fleet by @brandtbucher for commit bea2cff 🤖 If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again. |
The one buildbot failure looks unrelated, and seems to be affecting other PRs as well. |
This merges all numeric
BINARY_*
andINPLACE_*
instructions into oneBINARY_OP
instruction. As a consequence, theBINARY_ADD
andBINARY_MULTIPLY
specialization families are merged into a newBINARY_OP
family too.I prefer this new approach over the more complicated one taken in #29418. It simplifies the specialization logic for all operators (for example,
+=
and*=
now get specialized the same as+
and*
, basically for free).Performance is unchanged vs
main
:https://bugs.python.org/issue45636