-
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/asm: noise and bad assembly for constants on arm64 #16226
Comments
I observe that in cmd/internal/obj/arm64/asm7.go the line that prints that message is preceded just above by the comment // TODO(aram): remove. |
Sure, though the message itself is arguably legitimate. We shouldn't even be in that code for the smaller constants. |
CL https://golang.org/cl/24643 mentions this issue. |
I think this is down to arm64 bitwise immediates being encoded in an unusual scheme that Go's backend does not attempt to handle at all, which is #10111. I have a start of some code to address this in https://github.com/mwhudson/go/tree/bimm but I'm not super excited to finish it... |
Yes. Constant encoding on arm64 is serious bussiness. There are many different ways you can encode constant loads on arm64. Some of them survived several attempts of debugging, so they were disabled, leading to this observed behavior. |
CL https://golang.org/cl/26631 mentions this issue. |
What version of Go are you using (
go version
)?go version go1.6.2 linux/amd64 (also happens at tip, 92ce6c20)
What operating system and processor architecture are you using (
go env
)?What did you do?
What did you expect to see?
I expected it to assembly silently and produce four ORR instructions using shifted immediates (maybe the first one would need a constant from the constant pool).
What did you see instead?
The assembler prints the following messages:
Despite these messages, the build succeeds. However, all four ORRs are compiled to first load the constant from the constant pool, even though most of them could clearly be encoded as immediate ORRs.
Worse, the first ORR is compiled to use a 32-bit constant, which isn't even big enough for the constant, so it winds up ORR'ing 0.
This can be clearly seen in the objdump output:
The text was updated successfully, but these errors were encountered: