Skip to content
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: suboptimal compilation of 64-bit OMOD for 386/arm #15010

Closed
mdempsky opened this issue Mar 29, 2016 · 3 comments
Closed

cmd/compile: suboptimal compilation of 64-bit OMOD for 386/arm #15010

mdempsky opened this issue Mar 29, 2016 · 3 comments

Comments

@mdempsky
Copy link
Member

Compiling:

package p

func f(t int64) int64 {
        return t%1e9
}

for 386 or arm compiles as

func f(t int64) int64 {
        return t - runtime.int64div(t, 1e9) * 1e9
}

even though we're not able to do anything to optimize the * 1e9 multiplication. We might as well just call runtime.int64mod.

@minux
Copy link
Member

minux commented Mar 29, 2016 via email

@mdempsky
Copy link
Member Author

@minux Looking at https://github.com/golang/go/blob/master/src/runtime/vlrt.go, it seems like there should be. int64div and int64mod both just call a common dodiv function that calculates (quotient, remainder), and then they return the appropriate value. So they seem like they should be roughly identical in cost.

The int64div form also costs 48 extra bytes of 386 instructions and 52 extra bytes of arm instructions compared to just calling int64mod.

@bradfitz bradfitz added this to the Unplanned milestone Apr 7, 2016
@ALTree
Copy link
Member

ALTree commented Dec 18, 2017

Both go1.9 and go1.10 generate a int64mod call on 386 and arm, so I'm assuming this is fixed.

@ALTree ALTree closed this as completed Dec 18, 2017
@golang golang locked and limited conversation to collaborators Dec 18, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants