-
Notifications
You must be signed in to change notification settings - Fork 18.1k
runtime: better support for 64bit div/mod operations on 32bit platforms #19509
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
Comments
If these optimizations sound reasonable i can work on this for 1.9/1.10 after i have my current projects for 1.9 are submitted. |
SGTM. We even already have this, although it's called dodiv at the moment.
The compiler should already do this. Worth double-checking, though. |
It's probably also work taking a brief look at the code that the compiler generates for vlrt.go. It was tuned for the old backend. |
about 2. I checked before and after the issue creation :) The compiler does not simplify a div with 64bit operands on 32bit:
uses a "CALL runtime.uint64div(SB)" |
:) I see. Both seem worth fixing, then. Independently, I wonder whether it's worth adding an int32 code path, where we do all the work with int32s instead of int64s, for values that fit in 32 bits (which is probably almost all of them in practice). Might even be cheaper on 64 bit machines. Probably worth a benchmarking experiment. |
encountered in https://go-review.googlesource.com/c/38071/:
assuming x and y are uint64:
only uses a single DIV instruction on amd64 however on 386 this makes a runtime call to
uint64div and one to uint64mod.
The text was updated successfully, but these errors were encountered: