cmd/compile: weird asymmetry in when constants get registers #33580
Comments
|
Looks like this kind of depends on luck of the draw. The results of the ANDQ must go into one of the input registers. If the register allocator picks the constant input, then that constant must be reloaded when it is used again. If it picks the variable input, then the constant is still in a register for the next use. There's code in there to pick the input that is dead over the one that isn't. For some reason that code isn't doing the right thing. We'll look at this for 1.14. bad good |
|
Ohhh, interesting. I had been thinking of this as two separate issues -- one being reloading the constant for each set of uses, one being reloading it immediately for two consecutive uses -- but if the constant were inclined to stick around, it'd probably end up getting loaded once and used eight times, which would presumably affect performance at all. Some of what's happening seems to be that the two sets of operations (one on the first four words, one on the second four words) are written interleaved, but the compiler quite reasonably collates them. Which I assume reduces register pressure, but also means that all the uses of a given constant aren't together. There's some other weird stuff in here; moving the constant declarations to right above where they're used almost always makes them not get registers. I doubt that's related, but who knows, maybe it is. |
odeke-em
changed the title
andybons
added
the
NeedsInvestigation
|
Change https://golang.org/cl/199559 mentions this issue: |
What version of Go are you using (
go version)?1.12.
Does this issue reproduce with the latest release?
Seems to.
What operating system and processor architecture are you using (
go env)?amd64
What did you do?
STUPID THINGS. I got hypnotized by trying to mess with the code for a bit of bit-swizzling in order to improve compiler output. A helpful person in #performance on gopher slack pointed out that the compiler did a better job with constants if you assigned them to variables, and indeed, this is so.
Sometimes.
https://godbolt.org/z/ISgMpH
In this code, the relevant bits are four constants:
and some assignments to them:
and then a bunch of code using those values.
The code ends at line 174 of the assembly with both lines uncommented, or only the second uncommented. If the first is uncommented, it ends at line 160. But what's going on appears to be non-obvious; uncommenting that line isn't necessarily replacing instances of that value in the code with register references. If you split it out, each of the two "hi" values appears to cause a reduction of about 7 lines of code. Uncommenting the "lo" values has no effect.
Changing which value is which, or which kinds of shifts each value is used with, doesn't seem to change this, nor does changing the order they're used in. So it's not the sign bit, it's not "is used with left (or right) shifts", it's not "the one that gets used first gets priority"... I have no idea why they behave differently.
What did you expect to see?
I would expect the lines to have essentially interchangeable effects.
What did you see instead?
Lots of repeated loads of some values but not others.
The text was updated successfully, but these errors were encountered: