cmd/compile: improve escape analysis understanding of tree structures

[josharian]

package x

type N struct {
    left *N
    t    string
}

func f(n *N) {
    n.t = n.left.t
}

$ go tool compile -m -m e.go
e.go:8: leaking param content: n
e.go:8:     from n.left (dot of pointer) at e.go:9
e.go:8:     from n.left.t (dot of pointer) at e.go:9
e.go:8:     from n.t (star-dot-equals) at e.go:9

I believe that n should not escape here.

This arises in the compiler. It is one of the reasons that typecheck1's np argument escapes. (The new escape analysis explainer is very exciting.) 15% of the allocations in the compiler are *gc.Node, almost all of them due to moving *gc.Node parameters to the heap for calls to typecheck1. (After *gc.Node come gc.Nodes at 9%, gc.Node at 8.5%, []*gc.Node at 5.5%, and string at 5%.)

This strikes me as hard to fix in the general case, but figured it was worth checking.

@dr2chase

[dsnet]

This is related to (if not a duplicate of) #13493.

[gopherbot]

CL https://golang.org/cl/20959 mentions this issue.

[gopherbot]

Change https://golang.org/cl/126395 mentions this issue: cmd/compile/internal/gc: better handling of self-assignments in esc.go

[quasilyte]

I may be wrong, but this kind of inference may be impossible in the current model.

type N struct {
  left *N
  t    *object
}

func f(n *N) {
  // What if n.left allocated on stack, and n.left.t also does not escape.
  // Here, if we not assume n param as leaking contents,
  // and if n.left happens to have shorter lifetime than n,
  // we will store dead pointer into n.t that violates memory
  // guarantees, as far as I can tell.
  n.t = n.left.t
}

So, the conservative (and safe) action is to leak param content.