Register allocation weirdness with VPGATHERDD

[dominikh]

This

func foobar() {
	TEXT("foobar", 0, "func()")

	mask := YMM()
	base := GP64()
	indices := YMM()
	for range 10 {
		out := YMM()
		VPGATHERDD(mask, Mem{Base: base, Index: indices, Scale: 4}, out)
	}
}

generates this:

TEXT ·foobar(SB), $0
	VPGATHERDD Y0, (AX)(Y1*4), Y2
	VPGATHERDD Y0, (AX)(Y1*4), Y3
	VPGATHERDD Y0, (AX)(Y1*4), Y4
	VPGATHERDD Y0, (AX)(Y1*4), Y5
	VPGATHERDD Y0, (AX)(Y1*4), Y6
	VPGATHERDD Y0, (AX)(Y1*4), Y7
	VPGATHERDD Y0, (AX)(Y1*4), Y8
	VPGATHERDD Y0, (AX)(Y1*4), Y9
	VPGATHERDD Y0, (AX)(Y1*4), Y10
	VPGATHERDD Y0, (AX)(Y1*4), Y1

If we bump the number up to 32, we'll get an allocation failure because we've run out of registers. I don't see why the destination registers would be kept alive indefinitely.

[dominikh]

It seems to be because the output register is considered read+write, read because results get merged based on the mask. Explicitly writing to the outputs beforehand (e.g. clearing them with VPXOR) fixes this problem. Is there a way to "fake" a write, without producing an actual instruction?

[dominikh]

I wonder, however, if a virtual register that hasn't been written to yet should even be considered live since the beginning of the function. If it were a physical register, one could argue that it might be part of a custom calling convention, but not so for a virtual one.