cmd/compile: liveness analysis conservative for compound objects

[randall77]

func f(data []byte) {
	dataSize := len(data)
	g(data)
	runtime.GC()
	global = dataSize
}

func g([]byte)

var global int

The compiler reports (with -live) that data is live at the runtime.GC call. In fact, only the .len field of data is live at that point. But because we track liveness by variable, if any field of that variable is live whole variable is live. This means data will be retained unnecessarily by the garbage collector.

The generated code contains:

	0x001d 00029 (tmp1.go:7)	MOVQ	"".data+40(SP), AX
	0x0022 00034 (tmp1.go:7)	MOVQ	AX, (SP)
	0x0026 00038 (tmp1.go:7)	MOVQ	"".data+48(SP), AX
	0x002b 00043 (tmp1.go:7)	MOVQ	AX, 8(SP)
	0x0030 00048 (tmp1.go:7)	MOVQ	"".data+56(SP), CX
	0x0035 00053 (tmp1.go:7)	MOVQ	CX, 16(SP)
	0x003a 00058 (tmp1.go:7)	CALL	"".g(SB)
	0x003f 00063 (tmp1.go:8)	CALL	runtime.GC(SB)
	0x0044 00068 (tmp1.go:9)	MOVQ	"".data+48(SP), AX
	0x0049 00073 (tmp1.go:9)	MOVQ	AX, "".global(SB)

Even though the code looks like it reads the length first, the compiler postpones that read until after the runtime.GC call (so it doesn't have to issue a pointless spill).

Two solutions come to mind. One is to track liveness of individual pointer fields of variables, instead of whole variables. That would work, but could be expensive for variables which have lots of pointer fields. It also isn't possible to do precisely for variables which are arrays of pointers and have non-constant indexes.

The other solution is to ignore reads of scalars when doing the liveness analysis, as the results of the liveness analysis are only used by the GC. This is more of a hack but would be a simpler fix for the code in this issue.

[mdempsky]

Ignoring reads of scalar fields during liveness analysis was my first thought too.

[randall77]

It's not trivial to check the scalarness of a read in plive.go.
Usually it's easy, just check the type of the result.
Some reads return value/memory tuples, like MOVQatomicload.
Trickier still is ADDQload, which may be adding a scalar from memory to a pointer and generating a pointer result. Just because the result is a pointer doesn't mean the value being read from the variable is a pointer.

If we could extract the offset+size of the read, we could check in the type of the variable directly.

[mdempsky]

If we could extract the offset+size of the read, we could check in the type of the variable directly.

Isn't the offset already in AuxInt? We'd just need to encode the size of the read in the ssa.Op's SymEffects (at least for reads up to word size).

[randall77]

Yeah, the offset info is there. We'd have to switch on the aux type, there are a few others like symValAndOff.

[randall77]

Punting to 1.13.

[randall77]

Punting to 1.14.