cmd/compile: conditional escape analysis (or better synergy with inlining)

[adonovan]

(I'm certain this idea is not new, but the only related issues I can find are #72036 and #74364, which are both narrower.)

Inlining and escape analysis are not fully synergistic, presumably due to phase ordering. Thus even when a call is melted away, the conservative judgments of the escape analysis are not refined for the context of the call.

For example, although the compiler eliminates the call to f in this code:

type S struct{ x *int }

func f(ptr *S) {
	ptr.x = new(int)
}

func g() {
	var s S
	f(&s)
	print(s.x)
}

it does not produce object code equivalent to this program:

func g() {
	var s S
	s.x = new(int)
	print(s.x)
}

because the escape analysis of f determined that new(int) escapes, even though it does not escape in the context of the particular call from g.

If the phases of inlining and escape analysis were reversed, the two programs would generate identical code. Alternatively, the phase ordering could be retained but the inliner's summary of function f could be parameterized over a caller-supplied allocator, which in the case of this call would be a stack allocator.

[nicholashusin]

(I'm certain this idea is not new, but the only related issues I can find are #72036 and #74364, which are both narrower.)

#76957 is related too I think?

[gabyhelp]

Related Issues

• cmd/compile: Use dead code elimination after inlining for escape analysis #76957
• cmd/compile: missed escape analysis opportunity #5919
• cmd/compile: recursive functions are escape analyzed context insensitively #62501
• cmd/compile: improve escape analysis fidelity #33981 (closed)
• cmd/compile: improve escape analysis of make([]T, n) where n is non-constant #20533
• cmd/compile: escape analysis overconservative for recursive calls #13547
• cmd/compile: inline doesn't help for escape analysis #48660 (closed)
• cmd/compile: inlining after devirtualization #52193 (closed)
• cmd/gc: inlining vs escape analysis bug #4360 (closed)
• cmd/compile: avoid allocations for some return values #22081

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[thepudds]

Hi @adonovan, FWIW, I suspect the behavior you are reporting in these specific examples is not really related to the ordering of inlining vs. escape analysis, and not strictly speaking due to inlining.

I'd need to look more to be sure, but I believe it is likely the ir.ODOTPTR on the LHS of the assignment that causes new(int) to escape in your first example (the "bad" example).

In particular, I think the main difference is that in the first case, f is operating on a pointer to a struct, so ptr.x is an ir.ODOTPTR, and that's true when f is inlined as well as when it is not inlined:

func f(ptr *S) {
	ptr.x = new(int) // "new(int) escapes to heap"
}

On the other hand, in your second example (the "good" case), s is not a pointer, so s.x is not an ir.ODOTPTR:

func g() {
	var s S
	s.x = new(int) // "new(int) does not escape"
	print(s.x)
}

If I manually inline your first example but now keep an ir.ODOTPTR on the LHS of the assignment, the new(int) still escapes (with no inlining in play here):

func gManualInline() {
	var s S
	ptr := &s
	ptr.x = new(int) // "new(int) escapes to heap"
	print(s.x)
}

I've noodled a bit in the past on how to improve this behavior. I think there are a few different reasons escape analysis does this today (partly I think as simplification of tracking, but also the current behavior avoids making certain mistakes with pointers that have different lifetimes).

I just now put together a local escape analysis change that handles your different examples without escaping. (Part of the approach is identifying that the struct variable on the LHS of the ir.ODOTPTR is declared locally in the same function as the RHS of the assignment, which means escape analysis can have more knowledge of the relative lifetimes. A struct pointer can still escape for many other reasons, such as if it is returned from the function, but it no longer immediately triggers an escape due to the ir.ODOTPTR assignment. And with the change, the current phase ordering of inlining before escape analysis is helpful, because it means more things can be in the same function after inlining.)

It's an incomplete change right now, but I'll look at trying to solidify it for the 1.27 cycle.

In any event, there's some more nuance here (and really I need to look more carefully at your example, and some related cases not directly covered by your example, etc.), so please consider this a quick & preliminary comment.