]> Cypherpunks repositories - gostls13.git/commit
[release-branch.go1.3] cmd/gc: two escape analysis fixes
authorRuss Cox <rsc@golang.org>
Wed, 11 Jun 2014 21:00:17 +0000 (17:00 -0400)
committerRuss Cox <rsc@golang.org>
Wed, 11 Jun 2014 21:00:17 +0000 (17:00 -0400)
commit8ef4135731a578744de2cbaaaea8bc8e2a584317
tree1dcdde85fe258b6479e6c229f9a96e100b64e05e
parent16367614fbcd4ccdc6662e71bea76f3fbe6a7545
[release-branch.go1.3] cmd/gc: two escape analysis fixes

««« CL 108860043 / f153208c0a0e
cmd/gc: fix escape analysis for &x inside switch x := v.(type)

The analysis for &x was using the loop depth on x set
during x's declaration. A type switch creates a list of
implicit declarations that were not getting initialized
with loop depths.

Fixes #8176.

LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/108860043
»»»

««« CL 108870044 / 331dbd4a6334
cmd/gc: fix &result escaping into result

There is a hierarchy of location defined by loop depth:

        -1 = the heap
        0 = function results
        1 = local variables (and parameters)
        2 = local variable declared inside a loop
        3 = local variable declared inside a loop inside a loop
        etc

In general if an address from loopdepth n is assigned to
something in loop depth m < n, that indicates an extended
lifetime of some form that requires a heap allocation.

Function results can be local variables too, though, and so
they don't actually fit into the hierarchy very well.
Treat the address of a function result as level 1 so that
if it is written back into a result, the address is treated
as escaping.

Fixes  issue 8185 .

LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/108870044
»»»

LGTM=r
R=golang-codereviews, r
CC=bradfitz, golang-codereviews, iant
https://golang.org/cl/107930044
src/cmd/gc/esc.c
test/escape2.go