cmd/compile: worse performance looping through arrays identifiable at compile time

[seebs]

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]

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.