I suspect this would require a finer-grained escape analysis. Contrast these:

  f := new(int)
  doesntEscape(f)
  f = new(int)
  escapes(f)

  x := new(int)
  doesntEscape(x)
  y := new(int)
  escapes(y)

There's only one declaration in the first example. Escape analysis works on declarations. So f has to be declared as escaping. In contrast, the second example has 2 declarations so x can be seen to not escape.

I guess escape analysis would have to be augmented to split declarations into unconnected subsets somehow and then treat each subset independently.

@dr2chase

Interesting...

Escape analysis works on declarations.

Does that change with SSA? I would expect escape analysis to apply to SSA variables/slots/whatever rather than source variables.

No change here, sorry.

@randall77 - Your example does not escape now.

package main

func main() {
	f := new(int)
	f1(f)
	f = new(int)
	f2(f)
}

//go:noinline
func f1(i *int) {
	_ = i
}

//go:noinline
func f2(i *int) {
	_ = i
}

$gotip build -gcflags='-m' funnel_logger.go
# command-line-arguments
./funnel_logger.go:11:9: f1 i does not escape
./funnel_logger.go:16:9: f2 i does not escape
./funnel_logger.go:4:10: main new(int) does not escape
./funnel_logger.go:6:9: main new(int) does not escape

Has anything changed ?

gotip version
go version devel +e96c4ace9c Mon Mar 18 10:50:57 2019 +0530 linux/amd64

No, this still doesn't work. You need to declare f2 like:

//go:noinline
func f2(i *int) {
	sink = i
}

var sink *int

Then you get

/Users/khr/gowork/issue18300.go:11:9: f1 i does not escape
/Users/khr/gowork/issue18300.go:16:9: leaking param: i
/Users/khr/gowork/issue18300.go:4:10: new(int) escapes to heap
/Users/khr/gowork/issue18300.go:6:9: new(int) escapes to heap

Still an issue with newescape. Should be fixed by porting escape analysis to SSA (#31501); maybe fixable separately, but probably not worth the complexity.