cmd/compile: new escape analysis implementation doesn't heap-allocate pointer

[dsnet]

Apache Beam has a function as follows:

func LoadFunction(ptr uintptr, t reflect.Type) interface{} {
	v := reflect.New(t).Elem()
	*(*uintptr)(unsafe.Pointer(v.Addr().Pointer())) = (uintptr)(unsafe.Pointer(&ptr))
	return v.Interface()
}

When compiled on Go1.12 with -gcflags=-m, we see:

functions.go:43: &ptr escapes to heap

When compiled on Go1.13 with -gcflags=-m, the fact that &ptr escapes is no longer true. The effect of this change is a subtle memory corruption where since &ptr now points to the heap, rather than a copy of the value on the stack.

Git bisect reports that the issue is due to CL/170448, which seems to suggest that this breakage is intentional. The fix the Beam code is relatively straight forward by manually allocating ptr on the heap.

I'm filing an issue to confirm that this is an expected regression.

\cc @mdempsky @dr2chase

[cherrymui]

I think this was intentional. The assignment is done as integer assignment, not pointer assignment, so it does not form an escape edge. The old escape analysis was a bit conservative on this.

[mdempsky]

Yeah, the change was intentional. That LoadFunction code is not using unsafe.Pointer safely according to https://golang.org/pkg/unsafe/#Pointer

Easiest fix would be:

*(**uintptr)(unsafe.Pointer(v.Addr().Pointer())) = &ptr

[andybons]

Closing as this is confirmed intentional behavior. Thanks, @mdempsky and @cherrymui!