-
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: inconsistent float64 behaviour between arm64 and amd64 #36536
Comments
The spec says (https://golang.org/ref/spec#Arithmetic_operators):
That is, Go has never promised to produce bit-identical results on different architectures. I suspect that is what is happening here, but leaving the issue open for investigation or discussion. |
Yes, that's why I asked at go-nuts. The thing that tipped the balance is that I see a difference between in slice and single value versions of the code. Also note that the original code where the issue was identified expressed the mul and add on different lines, and so should not have been fused. Despite this, amd64 behaved the same way, and I am unable to get the same behaviour as arm64 by interposing explicit |
So it does look like it's due to that, just not in the direction I was thinking. On arm64 a fused multiply sub instruction is generated, but on amd64, a mul and sub set are emitted. Adding an explicit |
Yes, this is the arm64 backend using a fused multiply-subtract to compute the result. invNeg is not exactly |
Thanks. So the surprising thing is that in the old code, where the expressions were over two lines
the fused operation is still generated. I would have thought that the |
You can only prohibit the fusing with an explicit |
Yes, just confirmed that, the second line would need to be |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
inv.go: https://play.golang.org/p/yqox_9PRxI1
div.go: https://play.golang.org/p/8HhGeB-rUpn
Note that while this terminal session is all run on one machine using qemu-user for arm64, the same behaviour is seen on real arm64 hardware.
What did you expect to see?
Matching behaviour between arm64 and amd64.
What did you see instead?
Floating point difference for one approach.
This difference is only seen when the floats are in a slice, the equivalent in a single value behaves as expected.
The text was updated successfully, but these errors were encountered: