-
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: In bits.Len(x|1), compiler doesn't realize argument is never zero #51964
Labels
Comments
Change https://go.dev/cl/396034 mentions this issue: |
Change https://go.dev/cl/396035 mentions this issue: |
bits.Len32() still outputs unnecessary code for nonzero arguments. As it does x := uint64(arg)*2 + 1 to ensure a nonzero argument for BSFQ rather than use a conditional move after. |
gopherbot
pushed a commit
that referenced
this issue
Mar 31, 2022
This fixes two independent problems: We normally propagate desired registers backwards through opcodes that are marked resultInArg0. Unfortunately for the desired register computation, ADDQconst is not marked as resultInArg0. This is because the amd64 backend can write it out as LEAQ instead if the input and output registers don't match. For desired register purposes, we want to treat ADDQconst as resultInArg0, so that we get an ADDQ instead of a LEAQ if we can. Desired registers don't currently work for tuple-generating opcodes. Declare that the desired register applies to the first element of the tuple, and propagate the desired register back through Select0. Noticed when fixing #51964 Change-Id: I83346b988882cd58c2d7e7e5b419a2b9a244ab66 Reviewed-on: https://go-review.googlesource.com/c/go/+/396035 Trust: Keith Randall <khr@golang.org> Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What version of Go are you using (
go version
)?What operating system and processor architecture are you using (
go env
)?What did you do?
The expression bits.Len64(x|1) occurs in output from a protobuf compiler, where it calculates the size of a varint.
What did you expect to see?
What did you see instead?
It looks like this could be solved by extending the following rule to handle BSRQ:
go/src/cmd/compile/internal/ssa/gen/AMD64.rules
Lines 2075 to 2076 in 0652274
The text was updated successfully, but these errors were encountered: