Skip to content
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: worse performance looping through arrays identifiable at compile time #48637

Open
seebs opened this issue Sep 26, 2021 · 1 comment
Open

Comments

@seebs
Copy link
Contributor

@seebs seebs commented Sep 26, 2021

https://play.golang.org/p/M86lbOnYaAJ

Example adapted a bit from a previous example contributed by TL on Gopher Slack: https://play.golang.org/p/L5Lzmk4UUS9

What version of Go are you using (go version)?

1.17

Does this issue reproduce with the latest release?

Yes, also on tip.

What operating system and processor architecture are you using (go env)?

amd64

What did you do?

Simple test program.

What did you expect to see?

Comparable code or at least not dramatically worse code for cases where the compiler can figure out the address at compile time.

What did you see instead?

When the pointers used in each function can be determined at compile time to be a specific object's address, every access into the object uses LEAQ and the address is not saved or reused. When the compiler has to do a runtime computation (such as using a variable index into an array), or needs to create the address as its own object that lives somewhere anyway, such as to call a non-inlined function, it uses LEAQ to obtain the address once, and then just does accesses through that address, which turns out to be significantly faster.

Slightly modified version of the example on godbolt.org:

https://godbolt.org/z/vjTGvqoz5

In this one, I modified one of the functions to use a constant address for one array-pointer, and a variable for the other, and sure enough, got the LEAQ only for one then.

@randall77
Copy link
Contributor

@randall77 randall77 commented Sep 26, 2021

The fact that the LEAQ value is made each time in the loop instead of once before entering the loop is #15808.
The compiler has not yet been taught about the MOVBLZXloadidx1 instruction - that instruction would probably be even better here, as we don't need to materialize the LEAQ value at all.

@randall77 randall77 added this to the Unplanned milestone Sep 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants