Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upcmd/compile: optimize variables in function calls as equivalent to constant-derived variables #29166
Comments
This comment has been minimized.
This comment has been minimized.
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 |
This comment has been minimized.
This comment has been minimized.
Thank you for the answer. Obviously, I expect most math.* functions to be pure. Comparing to gcc: https://godbolt.org/z/Iryl4h |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
For simple functions that's just inlining + constant-folding, both of which we should arguably do... |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
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.