code review 53940043: cmd/gc: do not follow uintptr passed as function argument

cmd/gc: do not follow uintptr passed as function argument

The escape analysis works by tracing assignment paths from
variables that start with pointer type, or addresses of variables
(addresses are always pointers).  It does allow non-pointers
in the path, so that in this code it sees x's value escape into y:

        var x *[10]int
        y := (*int)(unsafe.Pointer(uintptr(unsafe.Pointer(x))+32))

It must allow uintptr in order to see through this kind of
"pointer arithmetic".

It also traces such values if they end up as uintptrs passed to
functions. This used to be important because packages like
encoding/gob passed around uintptrs holding real pointers.

The introduction of precise collection of stacks has forced
code to be more honest about which declared stack variables
hold pointers and which do not. In particular, the garbage
collector no longer sees pointers stored in uintptr variables.
Because of this, packages like encoding/gob have been fixed.

There is not much point in the escape analysis accepting
uintptrs as holding pointers at call boundaries if the garbage
collector does not.

Excluding uintptr-valued arguments brings the escape
analysis in line with the garbage collector and has the
useful side effect of making arguments to syscall.Syscall
not appear to escape.

That is, this CL should yield the same benefits as
CL 45930043 (rolled back in CL 53870043), but it does
so by making uintptrs less special, not more.

[rsc, 2014-01-17 23:43:58]

Hello golang-codereviews@googlegroups.com,

I'd like you to review this change to
https://code.google.com/p/go/

[iant, 2014-01-18 00:41:00]

LGTM

[rsc, 2014-01-21 18:31:37]

*** Submitted as https://code.google.com/p/go/source/detail?r=619cbfc6f3e2 ***

cmd/gc: do not follow uintptr passed as function argument

The escape analysis works by tracing assignment paths from
variables that start with pointer type, or addresses of variables
(addresses are always pointers).  It does allow non-pointers
in the path, so that in this code it sees x's value escape into y:

        var x *[10]int
        y := (*int)(unsafe.Pointer(uintptr(unsafe.Pointer(x))+32))

It must allow uintptr in order to see through this kind of
"pointer arithmetic".

It also traces such values if they end up as uintptrs passed to
functions. This used to be important because packages like
encoding/gob passed around uintptrs holding real pointers.

The introduction of precise collection of stacks has forced
code to be more honest about which declared stack variables
hold pointers and which do not. In particular, the garbage
collector no longer sees pointers stored in uintptr variables.
Because of this, packages like encoding/gob have been fixed.

There is not much point in the escape analysis accepting
uintptrs as holding pointers at call boundaries if the garbage
collector does not.

Excluding uintptr-valued arguments brings the escape
analysis in line with the garbage collector and has the
useful side effect of making arguments to syscall.Syscall
not appear to escape.

That is, this CL should yield the same benefits as
CL 45930043 (rolled back in CL 53870043), but it does
so by making uintptrs less special, not more.

R=golang-codereviews, iant
CC=golang-codereviews
https://codereview.appspot.com/53940043