-
Notifications
You must be signed in to change notification settings - Fork 18.1k
cmd/compile: Optimise branches that could be behind other branches, to avoid running those branches when known to be false #46711
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
(CC @randall77) |
In your example a and b are declared uint32, but they also appear to have fields, eg b.num. Is this code correct? |
They are most definitely supposed to be uint32. |
That could be an important clue; sometimes the desugaring from field to value can defeat analysis |
I just tested, and it is also present with just a straight up EDIT: |
I'm not sure we should do this transformation in general. Whether this transformation helps depends on the input value distribution - if they are 1<<31 a lot of the time, the code is better as is. |
There could be some analysis on if the branch is likely to be taken. IIRC this is already done in one way or another (like optimizing for the branch predictor?). Then you could make a check that does this if it is determined the branch is highly unlikely, and a subset of another branch, and no returns in between that could be taken. I dont know if this is something you want to do in the gc, where compilation performance is also important, that is up to you. But I think that you could make programs faster on average using this optimization at a certain threshold. |
Uh oh!
There was an error while loading. Please reload this page.
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
What did you expect to see?
I expected this code to be compiled to something equivalent to
to avoid checking for
a == 1<<31 || b.num == 1<<31
when it is known to not be true.Of course this is only possible when all the operations in between are known to not affect the return, or have any other side-effects.
What did you see instead?
This optimization is not applied.
The text was updated successfully, but these errors were encountered: