You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was refactoring some code and after compiling to Go's assembly, I noticed that the code generated was an half optimized version of my code: https://play.golang.org/p/6E-AGvBCwvy
What did you expect to see?
I expected the compiler to compile away the entire function, producing only a RET instruction.
This we could fix. My only question is how often this case comes up. Do people really write loops that end up having no effect? We don't want to spend compile time on an optimization that will ~never trigger. If it comes for free as part of a larger optimization (some beefed up dead code elimination, say) then it might make sense.
As I said above, I found this while refactoring some code, so I guess this doesn't appear all that often. In fact, I ended up deleting the code in question, because it was a noop.
But now that I'm looking at it from a different angle, the compiler could be smarter in the following case: https://play.golang.org/p/Ggmd6V8FDd2
The return value is a constant, but currently the compiler generates the code with a loop. But the same question rises: how often does this appear in codebases?
What version of Go are you using (
go version
)?go version go1.11.1 windows/amd64
What did you do?
I was refactoring some code and after compiling to Go's assembly, I noticed that the code generated was an half optimized version of my code:
https://play.golang.org/p/6E-AGvBCwvy
What did you expect to see?
I expected the compiler to compile away the entire function, producing only a
RET
instruction.What did you see instead?
Instead, it generated the following instructions:
As you can see, the compiler got rid of the array-related operations, but kept the index-incrementing code.
The text was updated successfully, but these errors were encountered: