cmd/compile: avoidable construction of stack objects

[mdempsky]

Compiling the program below with -live shows that x gets turned into a stack object:

package p

var m map[int16]bool

func f() {
        var x struct { p *int; i int16 }
        x.i = g()
        m[x.i] = true
        h()
        j(x.i)
}

func g() int16
func h()
func j(int16)

This is because the assignment m[x.i] = true passes x.i by reference, causing x to get marked as addrtaken.

Note that the logically equivalent program that replaces m[x.i] = true with tmp := x.i; m[tmp] = true does not create a stack object for x.

[mdempsky]

Slightly more realistic test case. x here should not require a stack object either:

package p

var m map[interface{}]bool

func f() {
	x := g()
	m[x] = true
	h()
}

func g() interface{}
func h()

(Edit: Actually, it's an autotmp copy of x that gets the stack object, not x itself. But my larger point is that f shouldn't need stack objects at all, since we statically know the lifetime of all variables there.)

[gopherbot]

Change https://golang.org/cl/284412 mentions this issue: [dev.regabi] cmd/compile: convert OPANIC argument to interface{} during typecheck

[mdempsky]

So the issue here is that during walk we end up rewriting m[k] = v into roughly *mapassign(m, &k) = v. When we create the node for &k it marks k as addrtaken. In general, variables marked addrtaken require stack objects, because we don't track how long the pointer will stay alive.

But when we taking the address of a variable to pass it to a runtime function like mapassign, we often know the variable is going to stay live until the runtime function returns. In this case, we don't need the full generality of stack objects; instead, as long as we add VarLive ops after the call (or probably by using CallExpr.KeepAlive), then we can let liveness analysis and the stack maps take care of keeping the variable alive instead.

This probably requires splitting Addrtaken into two separate flags: one to represent that the variable "needs to be addressable" and a second to represent that "the variable needs a stack object to track its liveness". We would set both flags for variables that the user takes the address of. In at least some cases in later stages of the compiler, we may only need to set "needs to be addressable".

[gopherbot]

Change https://golang.org/cl/321711 mentions this issue: cmd/compile: add new flag to track whether variables need stack objects

[gopherbot]

Change https://golang.org/cl/321712 mentions this issue: cmd/compile: mark OVARLIVE variables not require stack objects

[gopherbot]

Change https://golang.org/cl/321714 mentions this issue: cmd/compile: do not mark stack object for map key passed to runtime function

[gopherbot]

Change https://golang.org/cl/321713 mentions this issue: cmd/compile: refactor walkIndexMap