cmd/compile: optimize variables in function calls as equivalent to constant-derived variables #29166
Comments
odeke-em
changed the title
|
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 envOutputWhat did you do?
go tool compile -S opt.goopt.goWhat 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
fooandbarfunctionsWhat did you see instead?
In
foofunction there are three calls ofmath.Logfunction which creates overhead in computing of constant value every time whenfoocalled.The text was updated successfully, but these errors were encountered: