-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
cmd/compile: arithmetic optimization for shifts #69635
Comments
There are no API changes here, so taking this out of the proposal process. |
Sounds reasonable. Note that this depends on architecture. On arm64 it is already just 2 instructions.
|
Only for "nice" mask constants, though. |
Change https://go.dev/cl/621357 mentions this issue: |
Change https://go.dev/cl/621755 mentions this issue: |
For #69635 Change-Id: Id5696dc9724c3b3afcd7b60a6994f98c5309eb0e Reviewed-on: https://go-review.googlesource.com/c/go/+/621755 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Pratt <mpratt@google.com>
Proposal Details
I have a simple expression optimization suggestion that I noticed in some of my code. The minimal snippet that produces the offending code is this:
In my actual code, the calculation on the first line is actually happening in another (inlined) function; this terser version leads to the same result:
Obviously, shift left and shift rights do not cancel each other out in the same way as additions and subtractions do, but they are almost close enough. Addition and subtraction will in fact be combined, also in the inlined-function case:
For combining shifts in the same way, an additional masking AND would be required, but if it is already there, it can be recycled to efficiently combine the shifts. Actually the operations do not even have to oppose each other. Combining two adds or two shifts in the same direction would work just as well.
For
x << i & m >> j
with constantsi
,j
andm
, the combined shifting distance d would bei-j
(ori+j
for<< <<
, or-i-j
for>> >>
, .. you get the idea). We would then end up with the optimized version:where
DIR-SHIFT
is the idealized shift operation in either direction depending on the polarity ofd
,and
SH
is whatever the original second shift direction was.The final result for the original function would thus be:
The text was updated successfully, but these errors were encountered: