cmd/compile: rewrite escape analysis

[mdempsky]

Despite repeated efforts, I'm still confused by our escape analysis code. Also, based on discussion with other compiler devs, apparently this difficulty understanding is not unique to me. It would be good to better document this code so we can hopefully simplify and improve it.

Some specific questions I've had trying to understand the code:

• The "Escape analysis" documentation has a very high-level explanation, but leaves me with more questions than answers:

  • It mixes discussion of "nodes" and "variables," which makes it unclear to me whether expressions other than ONAME Nodes are present in the flow graph. (I think they are, otherwise I can't make sense of how we know if new(T) can be stack allocated or not.) It also talks about "values" having addresses, when only variables do. Using terminology consistent with the Go spec would help, IMO.

  • It mentions storing edges between "pointer-containing nodes". It would be nice to understand how this is expected to work in the presence of unsafe.Pointer <-> uintptr conversions.

  • Pseudo-code like flow(closure, &var) is confusing too: what's the & here supposed to signify?

  • I can't make sense of the phrase "tags all variables of it can reach an & node as escaping".

• The Level godocs are super opaque to me:

  • I kind of understand the meaning of value, but I don't completely understand why adding the +1 and -1 values is sound.

  • I have no idea what a "maximum-copy-started-suffix-level" is, and the x.left.left, &Node{x}, etc. examples don't really help. I'm particularly confused because a Node can represent so many different operations depending on the Op, and I'm lost on what semantic meaning we're divining from syntactic tree depth.

• escAnalyze has a reflooding loop that keeps looping until fixed point. It's not obvious to me why this is necessary. (At least experimentally, I do see that "Reflooding foo" shows up when building the standard library with -m=3.)

/cc @dr2chase @cherrymui @paranoiacblack

[cherrymui]

I have no idea what a "maximum-copy-started-suffix-level" is, and the x.left.left, &Node{x}, etc. examples don't really help. I'm particularly confused because a Node can represent so many different operations depending on the Op, and I'm lost on what semantic meaning we're divining from syntactic tree depth.

If I understand correctly, the example assumes there is a type Node with a field left which is of type *Node, in the source code, instead of the Node representation of the AST in the compiler. This is particularly confusing because I think this refers to source code but uses a data type that is the same as the compiler's AST data type.

[cherrymui]

escAnalyze has a reflooding loop that keeps looping until fixed point. It's not obvious to me why this is necessary. (At least experimentally, I do see that "Reflooding foo" shows up when building the standard library with -m=3.)

The reflooding is added in CL https://go-review.googlesource.com/c/go/+/30693. Its CL description explains it. Probably we should add this as a comment.

[gopherbot]

Change https://golang.org/cl/121001 mentions this issue: cmd/compile: improve escape analysis explanation

[mdempsky]

Over the weekend, I reimplemented a basic variant of esc.go's escape analysis logic, and now I better understand how it works in practice and what the documentation is explaining.

One thing I still don't understand though is the handling of recursive functions. In particular, this bit:

// in a mutually recursive group we lose track of the return values
if e.recursive {
	for _, ln := range Curfn.Func.Dcl {
		if ln.Op == ONAME && ln.Class() == PPARAMOUT {
			e.escflows(&e.theSink, ln, e.stepAssign(nil, ln, ln, "returned from recursive function"))
		}
	}
}

It looks like in esccall that we handle recursive calls, including wiring their return values into the flow graph correctly (look for "function in same mutually recursive group. Incorporate into flow graph").

I tried disabling this code by adding recursive = false at the top of escAnalyze, and it somewhat changes the -m output (which does cause test/escape_because.go's f8 and f9 to fail), but it doesn't seem to change which variables actually need to be heap allocated.

This code comes from CL 6741044 (507fcf3). It's true that before that CL we lost track of the return values in mutually recursive function calls, but the CL appears to have added both. So maybe the "if e.recursive" logic was written first, then lvd@ decided to fix the return value tracking, but forgot to remove the original (now unnecessary) fix?

[dr2chase]

When I was working on this and thought I understood it, the recursive punt seemed necessary.
A test case demonstrating this would be tricky, however.

I also don't know that this is that worthwhile; I took a stab at handling recursion and even had a CL for it that I somewhat trusted, and it avoided practically no heap allocations, so I didn't pursue it. The problem is that if anything escapes, the this-field-versus-that-field precision is lacking, and so everything escapes.

I am however very interested in any writeup you can put together, because the algorithm is a real pain to understand.

[mdempsky]

So here's the basic idea I understand:

Escape analysis treats the control flow graph as a bunch of locations, and assignments between them. Individual assignments can involve addressing or an arbitrary number of dereferences. For example:

p = &q    // -1
p = q     //  0
p = *q    //  1
p = **q   //  2
...

Note that p = &&q is nonsensical as values can't be addressed, so the length of an edge can never be less than -1.

Assignments can also be to the "sink" (basically, the Go heap).

All Go language constructs can be lowered into this assignment graph. For example,

var x struct { f, g *int }
var u []*int

x.f = u[0]

can be represented as

x = *u

Assignments to global variables, through pointers, passing arguments to unknown functions, etc. are recorded as assignments to the sink. Also, if q has a greater loop depth than p, then p = &q needs to be treated as sink = &q.

This is an imprecise but conservative representation of data flow.

As an optimization, the Go source might lower into multiple edges between the same two locations; it's only necessary to track the shortest edge.

Once we have a graph representing one or more functions, we can walk the graph to compute each node's "distance" from the sink and from any return parameters. This is basically just a bunch of shortest-path computations, except that distance is bounded as non-negative. For example, if p has distance 0 from some location, and there's an edge p = &q, then q has distance 0 from that location too, not distance -1.

Finally, we can observe two things from the resulting distance computations:

1. If there's an edge p = &q where p has distance 0 from either the sink or any return parameter, then q escapes (i.e., must be heap allocated).

2. For each function func f(p1, p2, ..., pN) (r1, r2, ..., rM) we can record the (M+1)*N distances from (sink, r1, r2, ...) to (p1, p2, ...) for subsequent escape analysis passes that involve calls to f. (The parameter tags that esc.go generates are basically a quantized encoding of this information.)

--

Notably, esc.go doesn't exactly follow this approach. Instead of simply constructing a graph and walking it as I describe above, escassign/escflow construct a partial graph (synthesizing OADDR/ODEREF nodes in lieu of tracking edge lengths directly) and escflood/escwalk walk the remaining edges. The subsequent computations based on the distance calculations are also intermingled into the walking logic, and tracking/recording distances is much more complicated.

[dr2chase]

That's a nicer description than mine, I think. I am still trying to figure out an intuitive explanation of "suffixValue".

[mdempsky]

As best I can tell, the suffixValue logic is captured in my simplified description by having distances bottom out at 0.

Basically, it's to ensure that given

sink = &p
p = q

then p needs to be heap allocated, but q doesn't.

[mdempsky]

As an update, I have a WIP branch where I've written a new escape analysis pass. You can see the new code here: https://github.com/mdempsky/go/blob/esc5/src/cmd/compile/internal/gc/esc2.go

It's still a little rough and I need to add documentation and better debugging facilities. (The latter being mostly ad hocly developed while I bring it up to feature parity with esc.go.)

However, I believe it's about on par with esc.go in terms of correctness, and it's less than half the number of lines of code (1117 vs 2425).

It roughly follows the description I made above: the stmts/stmt/value/assign/call methods all trudge through the AST tracking pointer flows and constructing a graph of EscLocations, and then flood+walk do a simple walk over the graph identifying locations that escape and value flows from pointers to result parameters.

The graphs it builds also tend to be much smaller than esc.go's. For example:

# net/http      total   high watermark
locations:    5172646    10126    // esc2.go's nodes
edges:        4784956     9577    // esc2.go's edges
state:       12479460    25101    // esc.go's nodes
flow:         5826852    11793    // esc.go's edges

esc2.go only needed about 40% as many graph nodes as esc.go, and about 80% as many edges. There's room for further improvement here too.

My next immediate goal is continuing to dig through the differences in behavior between esc.go and esc2.go, and then polishing it up for review for the next dev cycle.