-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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: optimize variables in function calls as equivalent to constant-derived variables #29166
Comments
Thank you for filing this issue @notimesea and welcome to the Go project! I believe this is a tricky one: I'll page some experts who can help answer better or help move the needle forward /cc @josharian @randall77 @TocarIP |
Thank you for the answer. Obviously, I expect most math.* functions to be pure. Comparing to gcc: https://godbolt.org/z/Iryl4h |
We've been throwing around the idea of analyzing functions for "pureness" (side effects, etc.). We could use that info to do a better job here. I don't think we want to go down the road of evaluating functions at compile time. But we could run them once and cache the result if we knew the function was pure. |
I think you're thinking of #22971. Note that we do evaluate math.Sqrt(const) at compile time, although that is a special case because of hardware support for sqrt on some processors. |
For simple functions that's just inlining + constant-folding, both of which we should arguably do... |
Of course. I think Keith meant “special casing package math functions” to be evaluated at compile time. Note also that Exp is implemented in assembly, so it is not a candidate for inlining. And I don’t think math/bits has enough firepower yet for a Go rewrite, but it would be interesting to double-check, and to consider what extra API would be needed. |
Sure, if the function is inlineable and constant folds to a constant, then that is fine. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
go tool compile -S opt.go
opt.go
What did you expect to see?
At first I expect one call of math.Log and one call of math.Exp in both functions (due to optimizations of calling functions on constant which can be done in compile time).
Also I expect no difference in asm code in
foo
andbar
functionsWhat did you see instead?
In
foo
function there are three calls ofmath.Log
function which creates overhead in computing of constant value every time whenfoo
called.The text was updated successfully, but these errors were encountered: