2019-07-25 13:54:03 -06:00
|
|
|
// errorcheck -0 -m -l
|
2011-08-24 11:07:08 -06:00
|
|
|
|
2016-04-10 15:32:26 -06:00
|
|
|
// Copyright 2010 The Go Authors. All rights reserved.
|
2011-08-24 11:07:08 -06:00
|
|
|
// Use of this source code is governed by a BSD-style
|
|
|
|
// license that can be found in the LICENSE file.
|
|
|
|
|
2012-02-18 20:28:53 -07:00
|
|
|
// Test, using compiler diagnostic flags, that the escape analysis is working.
|
2012-02-23 21:09:53 -07:00
|
|
|
// Compiles but does not run. Inlining is disabled.
|
2012-02-18 20:28:53 -07:00
|
|
|
|
2014-09-24 13:20:03 -06:00
|
|
|
// escape2n.go contains all the same tests but compiles with -N.
|
|
|
|
|
2011-08-24 11:07:08 -06:00
|
|
|
package foo
|
|
|
|
|
2011-11-01 09:02:43 -06:00
|
|
|
import (
|
|
|
|
"fmt"
|
|
|
|
"unsafe"
|
|
|
|
)
|
2011-08-24 11:07:08 -06:00
|
|
|
|
|
|
|
var gxx *int
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo1(x int) { // ERROR "moved to heap: x$"
|
2019-04-01 12:58:33 -06:00
|
|
|
gxx = &x
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo2(yy *int) { // ERROR "leaking param: yy$"
|
2011-08-24 11:07:08 -06:00
|
|
|
gxx = yy
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo3(x int) *int { // ERROR "moved to heap: x$"
|
2019-04-01 12:58:33 -06:00
|
|
|
return &x
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
type T *T
|
2011-08-28 10:05:00 -06:00
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo3b(t T) { // ERROR "leaking param: t$"
|
2011-08-24 11:07:08 -06:00
|
|
|
*t = t
|
|
|
|
}
|
|
|
|
|
|
|
|
// xx isn't going anywhere, so use of yy is ok
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo4(xx, yy *int) { // ERROR "xx does not escape$" "yy does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
xx = yy
|
|
|
|
}
|
|
|
|
|
|
|
|
// xx isn't going anywhere, so taking address of yy is ok
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo5(xx **int, yy *int) { // ERROR "xx does not escape$" "yy does not escape$"
|
2019-04-01 12:58:33 -06:00
|
|
|
xx = &yy
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo6(xx **int, yy *int) { // ERROR "xx does not escape$" "leaking param: yy$"
|
2011-08-24 11:07:08 -06:00
|
|
|
*xx = yy
|
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo7(xx **int, yy *int) { // ERROR "xx does not escape$" "yy does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
**xx = *yy
|
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo8(xx, yy *int) int { // ERROR "xx does not escape$" "yy does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
xx = yy
|
|
|
|
return *xx
|
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func foo9(xx, yy *int) *int { // ERROR "leaking param: xx to result ~r2 level=0$" "leaking param: yy to result ~r2 level=0$"
|
2011-08-24 11:07:08 -06:00
|
|
|
xx = yy
|
|
|
|
return xx
|
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo10(xx, yy *int) { // ERROR "xx does not escape$" "yy does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
*xx = *yy
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo11() int {
|
|
|
|
x, y := 0, 42
|
2019-04-01 12:58:33 -06:00
|
|
|
xx := &x
|
|
|
|
yy := &y
|
2011-08-24 11:07:08 -06:00
|
|
|
*xx = *yy
|
|
|
|
return x
|
|
|
|
}
|
|
|
|
|
|
|
|
var xxx **int
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo12(yyy **int) { // ERROR "leaking param: yyy$"
|
2011-08-24 11:07:08 -06:00
|
|
|
xxx = yyy
|
|
|
|
}
|
|
|
|
|
2014-05-09 13:40:45 -06:00
|
|
|
// Must treat yyy as leaking because *yyy leaks, and the escape analysis
|
2013-03-15 02:03:45 -06:00
|
|
|
// summaries in exported metadata do not distinguish these two cases.
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func foo13(yyy **int) { // ERROR "leaking param content: yyy$"
|
2011-08-24 11:07:08 -06:00
|
|
|
*xxx = *yyy
|
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo14(yyy **int) { // ERROR "yyy does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
**xxx = **yyy
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo15(yy *int) { // ERROR "moved to heap: yy$"
|
2019-04-01 12:58:33 -06:00
|
|
|
xxx = &yy
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo16(yy *int) { // ERROR "leaking param: yy$"
|
2011-08-24 11:07:08 -06:00
|
|
|
*xxx = yy
|
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo17(yy *int) { // ERROR "yy does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
**xxx = *yy
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo18(y int) { // ERROR "moved to heap: y$"
|
2019-04-01 12:58:33 -06:00
|
|
|
*xxx = &y
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func foo19(y int) {
|
|
|
|
**xxx = y
|
|
|
|
}
|
|
|
|
|
|
|
|
type Bar struct {
|
2011-08-28 10:05:00 -06:00
|
|
|
i int
|
2011-08-24 11:07:08 -06:00
|
|
|
ii *int
|
|
|
|
}
|
|
|
|
|
|
|
|
func NewBar() *Bar {
|
2015-02-19 12:00:11 -07:00
|
|
|
return &Bar{42, nil} // ERROR "&Bar literal escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
cmd/compile: update escape analysis tests for newescape
The new escape analysis implementation tries to emit debugging
diagnostics that are compatible with the existing implementation, but
there's a handful of cases that are easier to handle by updating the
test expectations instead.
For regress tests that need updating, the original file is copied to
oldescapeXXX.go.go with -newescape=false added to the //errorcheck
line, while the file is updated in place with -newescape=true and new
test requirements.
Notable test changes:
1) escape_because.go looks for a lot of detailed internal debugging
messages that are fairly particular to how esc.go works and that I
haven't attempted to port over to escape.go yet.
2) There are a lot of "leaking param: x to result ~r1 level=-1"
messages for code like
func(p *int) *T { return &T{p} }
that were simply wrong. Here &T must be heap allocated unconditionally
(because it's being returned); and since p is stored into it, p
escapes unconditionally too. esc.go incorrectly reports that p escapes
conditionally only if the returned pointer escaped.
3) esc.go used to print each "leaking param" analysis result as it
discovered them, which could lead to redundant messages (e.g., that a
param leaks at level=0 and level=1). escape.go instead prints
everything at the end, once it knows the shortest path to each sink.
4) esc.go didn't precisely model direct-interface types, resulting in
some values unnecessarily escaping to the heap when stored into
non-escaping interface values.
5) For functions written in assembly, esc.go only printed "does not
escape" messages, whereas escape.go prints "does not escape" or
"leaking param" as appropriate, consistent with the behavior for
functions written in Go.
6) 12 tests included "BAD" annotations identifying cases where esc.go
was unnecessarily heap allocating something. These are all fixed by
escape.go.
Updates #23109.
Change-Id: Iabc9eb14c94c9cadde3b183478d1fd54f013502f
Reviewed-on: https://go-review.googlesource.com/c/go/+/170447
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
2019-04-02 15:44:13 -06:00
|
|
|
func NewBarp(x *int) *Bar { // ERROR "leaking param: x$"
|
2015-02-19 12:00:11 -07:00
|
|
|
return &Bar{42, x} // ERROR "&Bar literal escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func NewBarp2(x *int) *Bar { // ERROR "x does not escape$"
|
2015-02-19 12:00:11 -07:00
|
|
|
return &Bar{*x, nil} // ERROR "&Bar literal escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func (b *Bar) NoLeak() int { // ERROR "b does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
return *(b.ii)
|
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func (b *Bar) Leak() *int { // ERROR "leaking param: b to result ~r0 level=0$"
|
2019-04-01 12:58:33 -06:00
|
|
|
return &b.i
|
2012-01-12 04:08:40 -07:00
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func (b *Bar) AlsoNoLeak() *int { // ERROR "leaking param: b to result ~r0 level=1$"
|
2011-08-24 11:07:08 -06:00
|
|
|
return b.ii
|
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func (b Bar) AlsoLeak() *int { // ERROR "leaking param: b to result ~r0 level=0$"
|
2012-01-12 04:08:40 -07:00
|
|
|
return b.ii
|
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func (b Bar) LeaksToo() *int { // ERROR "leaking param: b to result ~r0 level=0$"
|
cmd/compile: silence esc diagnostics about directiface OCONVIFACEs
In general, a conversion to interface type may require values to be
boxed, which in turn necessitates escape analysis to determine whether
the boxed representation can be stack allocated.
However, esc.go used to unconditionally print escape analysis
decisions about OCONVIFACE, even for conversions that don't require
boxing (e.g., pointers, channels, maps, functions).
For test compatibility with esc.go, escape.go similarly printed these
useless diagnostics. This CL removes the diagnostics, and updates test
expectations accordingly.
Change-Id: I97c57a4a08e44d265bba516c78426ff4f2bf1e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/192697
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-30 11:56:30 -06:00
|
|
|
v := 0 // ERROR "moved to heap: v$"
|
2019-04-01 12:58:33 -06:00
|
|
|
b.ii = &v
|
2012-01-12 04:08:40 -07:00
|
|
|
return b.ii
|
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func (b *Bar) LeaksABit() *int { // ERROR "leaking param: b to result ~r0 level=1$"
|
cmd/compile: silence esc diagnostics about directiface OCONVIFACEs
In general, a conversion to interface type may require values to be
boxed, which in turn necessitates escape analysis to determine whether
the boxed representation can be stack allocated.
However, esc.go used to unconditionally print escape analysis
decisions about OCONVIFACE, even for conversions that don't require
boxing (e.g., pointers, channels, maps, functions).
For test compatibility with esc.go, escape.go similarly printed these
useless diagnostics. This CL removes the diagnostics, and updates test
expectations accordingly.
Change-Id: I97c57a4a08e44d265bba516c78426ff4f2bf1e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/192697
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-30 11:56:30 -06:00
|
|
|
v := 0 // ERROR "moved to heap: v$"
|
2019-04-01 12:58:33 -06:00
|
|
|
b.ii = &v
|
2012-01-12 04:08:40 -07:00
|
|
|
return b.ii
|
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func (b Bar) StillNoLeak() int { // ERROR "b does not escape$"
|
2012-01-12 04:08:40 -07:00
|
|
|
v := 0
|
2019-04-01 12:58:33 -06:00
|
|
|
b.ii = &v
|
2012-01-12 04:08:40 -07:00
|
|
|
return b.i
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func goLeak(b *Bar) { // ERROR "leaking param: b$"
|
2011-09-07 11:03:11 -06:00
|
|
|
go b.NoLeak()
|
|
|
|
}
|
|
|
|
|
2011-08-24 11:07:08 -06:00
|
|
|
type Bar2 struct {
|
2011-08-28 10:05:00 -06:00
|
|
|
i [12]int
|
2011-08-24 11:07:08 -06:00
|
|
|
ii []int
|
|
|
|
}
|
|
|
|
|
|
|
|
func NewBar2() *Bar2 {
|
2015-02-19 12:00:11 -07:00
|
|
|
return &Bar2{[12]int{42}, nil} // ERROR "&Bar2 literal escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func (b *Bar2) NoLeak() int { // ERROR "b does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
return b.i[0]
|
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func (b *Bar2) Leak() []int { // ERROR "leaking param: b to result ~r0 level=0$"
|
2019-04-01 12:58:33 -06:00
|
|
|
return b.i[:]
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func (b *Bar2) AlsoNoLeak() []int { // ERROR "leaking param: b to result ~r0 level=1$"
|
2011-08-24 11:07:08 -06:00
|
|
|
return b.ii[0:1]
|
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func (b Bar2) AgainNoLeak() [12]int { // ERROR "b does not escape$"
|
2012-01-12 04:08:40 -07:00
|
|
|
return b.i
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func (b *Bar2) LeakSelf() { // ERROR "leaking param: b$"
|
2019-04-01 12:58:33 -06:00
|
|
|
b.ii = b.i[0:4]
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func (b *Bar2) LeakSelf2() { // ERROR "leaking param: b$"
|
2011-08-24 11:07:08 -06:00
|
|
|
var buf []int
|
2019-04-01 12:58:33 -06:00
|
|
|
buf = b.i[0:]
|
2011-08-24 11:07:08 -06:00
|
|
|
b.ii = buf
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo21() func() int {
|
2015-01-19 12:59:58 -07:00
|
|
|
x := 42
|
2015-02-19 12:00:11 -07:00
|
|
|
return func() int { // ERROR "func literal escapes to heap$"
|
2015-01-19 12:59:58 -07:00
|
|
|
return x
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo21a() func() int {
|
2015-02-19 12:00:11 -07:00
|
|
|
x := 42 // ERROR "moved to heap: x$"
|
|
|
|
return func() int { // ERROR "func literal escapes to heap$"
|
2019-04-01 12:58:33 -06:00
|
|
|
x++
|
2015-01-19 12:59:58 -07:00
|
|
|
return x
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo22() int {
|
|
|
|
x := 42
|
2019-09-12 11:18:03 -06:00
|
|
|
return func() int { // ERROR "func literal does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
return x
|
|
|
|
}()
|
|
|
|
}
|
|
|
|
|
2015-01-19 12:59:58 -07:00
|
|
|
func foo23(x int) func() int {
|
2015-02-19 12:00:11 -07:00
|
|
|
return func() int { // ERROR "func literal escapes to heap$"
|
2015-01-19 12:59:58 -07:00
|
|
|
return x
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-01-19 12:59:58 -07:00
|
|
|
func foo23a(x int) func() int {
|
2015-02-19 12:00:11 -07:00
|
|
|
f := func() int { // ERROR "func literal escapes to heap$"
|
2015-01-19 12:59:58 -07:00
|
|
|
return x
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
return f
|
|
|
|
}
|
|
|
|
|
2015-01-19 12:59:58 -07:00
|
|
|
func foo23b(x int) *(func() int) {
|
2015-02-19 12:00:11 -07:00
|
|
|
f := func() int { return x } // ERROR "func literal escapes to heap$" "moved to heap: f$"
|
2019-04-01 12:58:33 -06:00
|
|
|
return &f
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo23c(x int) func() int { // ERROR "moved to heap: x$"
|
|
|
|
return func() int { // ERROR "func literal escapes to heap$"
|
2019-04-01 12:58:33 -06:00
|
|
|
x++
|
2015-01-19 12:59:58 -07:00
|
|
|
return x
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-08-24 11:07:08 -06:00
|
|
|
func foo24(x int) int {
|
2019-09-12 11:18:03 -06:00
|
|
|
return func() int { // ERROR "func literal does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
return x
|
|
|
|
}()
|
|
|
|
}
|
|
|
|
|
|
|
|
var x *int
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func fooleak(xx *int) int { // ERROR "leaking param: xx$"
|
2011-08-24 11:07:08 -06:00
|
|
|
x = xx
|
|
|
|
return *x
|
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func foonoleak(xx *int) int { // ERROR "xx does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
return *x + *xx
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo31(x int) int { // ERROR "moved to heap: x$"
|
2019-04-01 12:58:33 -06:00
|
|
|
return fooleak(&x)
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func foo32(x int) int {
|
2019-04-01 12:58:33 -06:00
|
|
|
return foonoleak(&x)
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
type Foo struct {
|
|
|
|
xx *int
|
2011-08-28 10:05:00 -06:00
|
|
|
x int
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
var F Foo
|
|
|
|
var pf *Foo
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func (f *Foo) fooleak() { // ERROR "leaking param: f$"
|
2011-08-24 11:07:08 -06:00
|
|
|
pf = f
|
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func (f *Foo) foonoleak() { // ERROR "f does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
F.x = f.x
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func (f *Foo) Leak() { // ERROR "leaking param: f$"
|
2011-08-24 11:07:08 -06:00
|
|
|
f.fooleak()
|
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func (f *Foo) NoLeak() { // ERROR "f does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
f.foonoleak()
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo41(x int) { // ERROR "moved to heap: x$"
|
2019-04-01 12:58:33 -06:00
|
|
|
F.xx = &x
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func (f *Foo) foo42(x int) { // ERROR "f does not escape$" "moved to heap: x$"
|
2019-04-01 12:58:33 -06:00
|
|
|
f.xx = &x
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo43(f *Foo, x int) { // ERROR "f does not escape$" "moved to heap: x$"
|
2019-04-01 12:58:33 -06:00
|
|
|
f.xx = &x
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo44(yy *int) { // ERROR "leaking param: yy$"
|
2011-08-24 11:07:08 -06:00
|
|
|
F.xx = yy
|
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func (f *Foo) foo45() { // ERROR "f does not escape$"
|
2011-08-28 10:05:00 -06:00
|
|
|
F.x = f.x
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2013-03-15 02:03:45 -06:00
|
|
|
// See foo13 above for explanation of why f leaks.
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func (f *Foo) foo46() { // ERROR "leaking param content: f$"
|
2011-08-28 10:05:00 -06:00
|
|
|
F.xx = f.xx
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func (f *Foo) foo47() { // ERROR "leaking param: f$"
|
2019-04-01 12:58:33 -06:00
|
|
|
f.xx = &f.x
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
var ptrSlice []*int
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo50(i *int) { // ERROR "leaking param: i$"
|
2011-08-24 11:07:08 -06:00
|
|
|
ptrSlice[0] = i
|
|
|
|
}
|
|
|
|
|
|
|
|
var ptrMap map[*int]*int
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo51(i *int) { // ERROR "leaking param: i$"
|
2011-08-24 11:07:08 -06:00
|
|
|
ptrMap[i] = i
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func indaddr1(x int) *int { // ERROR "moved to heap: x$"
|
2019-04-01 12:58:33 -06:00
|
|
|
return &x
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func indaddr2(x *int) *int { // ERROR "leaking param: x to result ~r1 level=0$"
|
2019-04-01 12:58:33 -06:00
|
|
|
return *&x
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func indaddr3(x *int32) *int { // ERROR "leaking param: x to result ~r1 level=0$"
|
2019-04-01 12:58:33 -06:00
|
|
|
return *(**int)(unsafe.Pointer(&x))
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
// From package math:
|
|
|
|
|
|
|
|
func Float32bits(f float32) uint32 {
|
2019-04-01 12:58:33 -06:00
|
|
|
return *(*uint32)(unsafe.Pointer(&f))
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func Float32frombits(b uint32) float32 {
|
2019-04-01 12:58:33 -06:00
|
|
|
return *(*float32)(unsafe.Pointer(&b))
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func Float64bits(f float64) uint64 {
|
2019-04-01 12:58:33 -06:00
|
|
|
return *(*uint64)(unsafe.Pointer(&f))
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func Float64frombits(b uint64) float64 {
|
2019-04-01 12:58:33 -06:00
|
|
|
return *(*float64)(unsafe.Pointer(&b))
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
// contrast with
|
2015-02-19 12:00:11 -07:00
|
|
|
func float64bitsptr(f float64) *uint64 { // ERROR "moved to heap: f$"
|
2019-04-01 12:58:33 -06:00
|
|
|
return (*uint64)(unsafe.Pointer(&f))
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func float64ptrbitsptr(f *float64) *uint64 { // ERROR "leaking param: f to result ~r1 level=0$"
|
2011-08-24 11:07:08 -06:00
|
|
|
return (*uint64)(unsafe.Pointer(f))
|
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func typesw(i interface{}) *int { // ERROR "leaking param: i to result ~r1 level=0$"
|
2011-08-24 11:07:08 -06:00
|
|
|
switch val := i.(type) {
|
|
|
|
case *int:
|
|
|
|
return val
|
|
|
|
case *int8:
|
2015-02-19 12:00:11 -07:00
|
|
|
v := int(*val) // ERROR "moved to heap: v$"
|
2019-04-01 12:58:33 -06:00
|
|
|
return &v
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func exprsw(i *int) *int { // ERROR "leaking param: i to result ~r1 level=0$"
|
2011-08-24 11:07:08 -06:00
|
|
|
switch j := i; *j + 110 {
|
|
|
|
case 12:
|
|
|
|
return j
|
|
|
|
case 42:
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
// assigning to an array element is like assigning to the array
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func foo60(i *int) *int { // ERROR "leaking param: i to result ~r1 level=0$"
|
2011-08-24 11:07:08 -06:00
|
|
|
var a [12]*int
|
|
|
|
a[0] = i
|
|
|
|
return a[1]
|
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo60a(i *int) *int { // ERROR "i does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
var a [12]*int
|
|
|
|
a[0] = i
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// assigning to a struct field is like assigning to the struct
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func foo61(i *int) *int { // ERROR "leaking param: i to result ~r1 level=0$"
|
2011-08-24 11:07:08 -06:00
|
|
|
type S struct {
|
2011-08-28 10:05:00 -06:00
|
|
|
a, b *int
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
var s S
|
|
|
|
s.a = i
|
|
|
|
return s.b
|
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo61a(i *int) *int { // ERROR "i does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
type S struct {
|
2011-08-28 10:05:00 -06:00
|
|
|
a, b *int
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
var s S
|
|
|
|
s.a = i
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// assigning to a struct field is like assigning to the struct but
|
|
|
|
// here this subtlety is lost, since s.a counts as an assignment to a
|
|
|
|
// track-losing dereference.
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo62(i *int) *int { // ERROR "leaking param: i$"
|
2011-08-24 11:07:08 -06:00
|
|
|
type S struct {
|
2011-08-28 10:05:00 -06:00
|
|
|
a, b *int
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
2019-09-12 11:18:03 -06:00
|
|
|
s := new(S) // ERROR "new\(S\) does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
s.a = i
|
2011-08-28 10:05:00 -06:00
|
|
|
return nil // s.b
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2011-08-28 10:05:00 -06:00
|
|
|
type M interface {
|
|
|
|
M()
|
|
|
|
}
|
2011-08-24 11:07:08 -06:00
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo63(m M) { // ERROR "m does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo64(m M) { // ERROR "leaking param: m$"
|
2011-08-24 11:07:08 -06:00
|
|
|
m.M()
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo64b(m M) { // ERROR "leaking param: m$"
|
2011-09-07 11:03:11 -06:00
|
|
|
defer m.M()
|
|
|
|
}
|
|
|
|
|
2011-08-24 11:07:08 -06:00
|
|
|
type MV int
|
2011-08-28 10:05:00 -06:00
|
|
|
|
2011-08-24 11:07:08 -06:00
|
|
|
func (MV) M() {}
|
|
|
|
|
|
|
|
func foo65() {
|
|
|
|
var mv MV
|
cmd/compile: silence esc diagnostics about directiface OCONVIFACEs
In general, a conversion to interface type may require values to be
boxed, which in turn necessitates escape analysis to determine whether
the boxed representation can be stack allocated.
However, esc.go used to unconditionally print escape analysis
decisions about OCONVIFACE, even for conversions that don't require
boxing (e.g., pointers, channels, maps, functions).
For test compatibility with esc.go, escape.go similarly printed these
useless diagnostics. This CL removes the diagnostics, and updates test
expectations accordingly.
Change-Id: I97c57a4a08e44d265bba516c78426ff4f2bf1e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/192697
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-30 11:56:30 -06:00
|
|
|
foo63(&mv)
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func foo66() {
|
cmd/compile: silence esc diagnostics about directiface OCONVIFACEs
In general, a conversion to interface type may require values to be
boxed, which in turn necessitates escape analysis to determine whether
the boxed representation can be stack allocated.
However, esc.go used to unconditionally print escape analysis
decisions about OCONVIFACE, even for conversions that don't require
boxing (e.g., pointers, channels, maps, functions).
For test compatibility with esc.go, escape.go similarly printed these
useless diagnostics. This CL removes the diagnostics, and updates test
expectations accordingly.
Change-Id: I97c57a4a08e44d265bba516c78426ff4f2bf1e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/192697
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-30 11:56:30 -06:00
|
|
|
var mv MV // ERROR "moved to heap: mv$"
|
|
|
|
foo64(&mv)
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func foo67() {
|
|
|
|
var mv MV
|
2019-09-12 11:18:03 -06:00
|
|
|
foo63(mv) // ERROR "mv does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func foo68() {
|
|
|
|
var mv MV
|
2015-02-19 06:27:32 -07:00
|
|
|
// escapes but it's an int so irrelevant
|
2015-02-19 12:00:11 -07:00
|
|
|
foo64(mv) // ERROR "mv escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo69(m M) { // ERROR "leaking param: m$"
|
2011-08-24 11:07:08 -06:00
|
|
|
foo64(m)
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo70(mv1 *MV, m M) { // ERROR "leaking param: m$" "leaking param: mv1$"
|
cmd/compile: silence esc diagnostics about directiface OCONVIFACEs
In general, a conversion to interface type may require values to be
boxed, which in turn necessitates escape analysis to determine whether
the boxed representation can be stack allocated.
However, esc.go used to unconditionally print escape analysis
decisions about OCONVIFACE, even for conversions that don't require
boxing (e.g., pointers, channels, maps, functions).
For test compatibility with esc.go, escape.go similarly printed these
useless diagnostics. This CL removes the diagnostics, and updates test
expectations accordingly.
Change-Id: I97c57a4a08e44d265bba516c78426ff4f2bf1e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/192697
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-30 11:56:30 -06:00
|
|
|
m = mv1
|
2011-08-24 11:07:08 -06:00
|
|
|
foo64(m)
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo71(x *int) []*int { // ERROR "leaking param: x$"
|
2011-08-24 11:07:08 -06:00
|
|
|
var y []*int
|
|
|
|
y = append(y, x)
|
|
|
|
return y
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo71a(x int) []*int { // ERROR "moved to heap: x$"
|
2011-08-24 11:07:08 -06:00
|
|
|
var y []*int
|
2019-04-01 12:58:33 -06:00
|
|
|
y = append(y, &x)
|
2011-08-24 11:07:08 -06:00
|
|
|
return y
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo72() {
|
|
|
|
var x int
|
|
|
|
var y [1]*int
|
2019-04-01 12:58:33 -06:00
|
|
|
y[0] = &x
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func foo72aa() [10]*int {
|
2015-02-19 12:00:11 -07:00
|
|
|
var x int // ERROR "moved to heap: x$"
|
2011-08-24 11:07:08 -06:00
|
|
|
var y [10]*int
|
2019-04-01 12:58:33 -06:00
|
|
|
y[0] = &x
|
2011-08-24 11:07:08 -06:00
|
|
|
return y
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo72a() {
|
|
|
|
var y [10]*int
|
|
|
|
for i := 0; i < 10; i++ {
|
2011-08-28 10:05:00 -06:00
|
|
|
// escapes its scope
|
cmd/compile: silence esc diagnostics about directiface OCONVIFACEs
In general, a conversion to interface type may require values to be
boxed, which in turn necessitates escape analysis to determine whether
the boxed representation can be stack allocated.
However, esc.go used to unconditionally print escape analysis
decisions about OCONVIFACE, even for conversions that don't require
boxing (e.g., pointers, channels, maps, functions).
For test compatibility with esc.go, escape.go similarly printed these
useless diagnostics. This CL removes the diagnostics, and updates test
expectations accordingly.
Change-Id: I97c57a4a08e44d265bba516c78426ff4f2bf1e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/192697
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-30 11:56:30 -06:00
|
|
|
x := i // ERROR "moved to heap: x$"
|
2019-04-01 12:58:33 -06:00
|
|
|
y[i] = &x
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo72b() [10]*int {
|
|
|
|
var y [10]*int
|
|
|
|
for i := 0; i < 10; i++ {
|
cmd/compile: silence esc diagnostics about directiface OCONVIFACEs
In general, a conversion to interface type may require values to be
boxed, which in turn necessitates escape analysis to determine whether
the boxed representation can be stack allocated.
However, esc.go used to unconditionally print escape analysis
decisions about OCONVIFACE, even for conversions that don't require
boxing (e.g., pointers, channels, maps, functions).
For test compatibility with esc.go, escape.go similarly printed these
useless diagnostics. This CL removes the diagnostics, and updates test
expectations accordingly.
Change-Id: I97c57a4a08e44d265bba516c78426ff4f2bf1e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/192697
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-30 11:56:30 -06:00
|
|
|
x := i // ERROR "moved to heap: x$"
|
2019-04-01 12:58:33 -06:00
|
|
|
y[i] = &x
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
return y
|
|
|
|
}
|
|
|
|
|
|
|
|
// issue 2145
|
|
|
|
func foo73() {
|
2019-09-12 11:18:03 -06:00
|
|
|
s := []int{3, 2, 1} // ERROR "\[\]int literal does not escape$"
|
2015-01-19 12:59:58 -07:00
|
|
|
for _, v := range s {
|
|
|
|
vv := v
|
|
|
|
// actually just escapes its scope
|
2015-02-19 12:00:11 -07:00
|
|
|
defer func() { // ERROR "func literal escapes to heap$"
|
2015-01-19 12:59:58 -07:00
|
|
|
println(vv)
|
|
|
|
}()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo731() {
|
2019-09-12 11:18:03 -06:00
|
|
|
s := []int{3, 2, 1} // ERROR "\[\]int literal does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
for _, v := range s {
|
2015-02-19 12:00:11 -07:00
|
|
|
vv := v // ERROR "moved to heap: vv$"
|
2011-08-28 10:05:00 -06:00
|
|
|
// actually just escapes its scope
|
2015-02-19 12:00:11 -07:00
|
|
|
defer func() { // ERROR "func literal escapes to heap$"
|
2019-04-01 12:58:33 -06:00
|
|
|
vv = 42
|
2015-01-19 12:59:58 -07:00
|
|
|
println(vv)
|
2011-08-24 11:07:08 -06:00
|
|
|
}()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo74() {
|
2019-09-12 11:18:03 -06:00
|
|
|
s := []int{3, 2, 1} // ERROR "\[\]int literal does not escape$"
|
2015-01-19 12:59:58 -07:00
|
|
|
for _, v := range s {
|
|
|
|
vv := v
|
|
|
|
// actually just escapes its scope
|
2015-02-19 12:00:11 -07:00
|
|
|
fn := func() { // ERROR "func literal escapes to heap$"
|
2015-01-19 12:59:58 -07:00
|
|
|
println(vv)
|
|
|
|
}
|
|
|
|
defer fn()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo74a() {
|
2019-09-12 11:18:03 -06:00
|
|
|
s := []int{3, 2, 1} // ERROR "\[\]int literal does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
for _, v := range s {
|
2015-02-19 12:00:11 -07:00
|
|
|
vv := v // ERROR "moved to heap: vv$"
|
2011-08-28 10:05:00 -06:00
|
|
|
// actually just escapes its scope
|
2015-02-19 12:00:11 -07:00
|
|
|
fn := func() { // ERROR "func literal escapes to heap$"
|
2019-04-01 12:58:33 -06:00
|
|
|
vv += 1
|
2015-01-19 12:59:58 -07:00
|
|
|
println(vv)
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
defer fn()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-08-31 14:23:37 -06:00
|
|
|
// issue 3975
|
|
|
|
func foo74b() {
|
2015-01-19 12:59:58 -07:00
|
|
|
var array [3]func()
|
2019-09-12 11:18:03 -06:00
|
|
|
s := []int{3, 2, 1} // ERROR "\[\]int literal does not escape$"
|
2015-01-19 12:59:58 -07:00
|
|
|
for i, v := range s {
|
|
|
|
vv := v
|
|
|
|
// actually just escapes its scope
|
2015-02-19 12:00:11 -07:00
|
|
|
array[i] = func() { // ERROR "func literal escapes to heap$"
|
2015-01-19 12:59:58 -07:00
|
|
|
println(vv)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo74c() {
|
2012-08-31 14:23:37 -06:00
|
|
|
var array [3]func()
|
2019-09-12 11:18:03 -06:00
|
|
|
s := []int{3, 2, 1} // ERROR "\[\]int literal does not escape$"
|
2012-08-31 14:23:37 -06:00
|
|
|
for i, v := range s {
|
2015-02-19 12:00:11 -07:00
|
|
|
vv := v // ERROR "moved to heap: vv$"
|
2012-08-31 14:23:37 -06:00
|
|
|
// actually just escapes its scope
|
2015-02-19 12:00:11 -07:00
|
|
|
array[i] = func() { // ERROR "func literal escapes to heap$"
|
2019-04-01 12:58:33 -06:00
|
|
|
println(&vv)
|
2012-08-31 14:23:37 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func myprint(y *int, x ...interface{}) *int { // ERROR "leaking param: y to result ~r2 level=0$" "x does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
return y
|
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func myprint1(y *int, x ...interface{}) *interface{} { // ERROR "leaking param: x to result ~r2 level=0$" "y does not escape$"
|
2019-04-01 12:58:33 -06:00
|
|
|
return &x[0]
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo75(z *int) { // ERROR "z does not escape$"
|
|
|
|
myprint(z, 1, 2, 3) // ERROR "1 does not escape" "2 does not escape" "3 does not escape" "... argument does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo75a(z *int) { // ERROR "z does not escape$"
|
|
|
|
myprint1(z, 1, 2, 3) // ERROR "1 does not escape" "2 does not escape" "3 does not escape" "... argument does not escape$"
|
cmd/gc: escape analysis to track flow of in to out parameters.
includes step 0: synthesize outparams, from 6600044
includes step 1,2: give outparams loopdepth 0 and verify unchanged results
generate esc:$mask tags, but still tie to sink if a param has mask != 0
from 6610054
adds final steps:
- have esccall generate n->escretval, a list of nodes the function results flow to
- use these in esccall and ORETURN/OAS2FUNC/and f(g())
- only tie parameters to sink if tag is absent, otherwise according to mask, tie them to escretval
R=rsc, bradfitz
CC=dave, gobot, golang-dev, iant, rsc
https://golang.org/cl/6741044
2012-10-29 06:38:21 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo75esc(z *int) { // ERROR "leaking param: z$"
|
2019-09-12 11:18:03 -06:00
|
|
|
gxx = myprint(z, 1, 2, 3) // ERROR "1 does not escape" "2 does not escape" "3 does not escape" "... argument does not escape$"
|
cmd/gc: escape analysis to track flow of in to out parameters.
includes step 0: synthesize outparams, from 6600044
includes step 1,2: give outparams loopdepth 0 and verify unchanged results
generate esc:$mask tags, but still tie to sink if a param has mask != 0
from 6610054
adds final steps:
- have esccall generate n->escretval, a list of nodes the function results flow to
- use these in esccall and ORETURN/OAS2FUNC/and f(g())
- only tie parameters to sink if tag is absent, otherwise according to mask, tie them to escretval
R=rsc, bradfitz
CC=dave, gobot, golang-dev, iant, rsc
https://golang.org/cl/6741044
2012-10-29 06:38:21 -06:00
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo75aesc(z *int) { // ERROR "z does not escape$"
|
2012-12-20 15:27:28 -07:00
|
|
|
var ppi **interface{} // assignments to pointer dereferences lose track
|
2015-02-19 12:00:11 -07:00
|
|
|
*ppi = myprint1(z, 1, 2, 3) // ERROR "... argument escapes to heap$" "1 escapes to heap$" "2 escapes to heap$" "3 escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo75aesc1(z *int) { // ERROR "z does not escape$"
|
cmd/compile: silence esc diagnostics about directiface OCONVIFACEs
In general, a conversion to interface type may require values to be
boxed, which in turn necessitates escape analysis to determine whether
the boxed representation can be stack allocated.
However, esc.go used to unconditionally print escape analysis
decisions about OCONVIFACE, even for conversions that don't require
boxing (e.g., pointers, channels, maps, functions).
For test compatibility with esc.go, escape.go similarly printed these
useless diagnostics. This CL removes the diagnostics, and updates test
expectations accordingly.
Change-Id: I97c57a4a08e44d265bba516c78426ff4f2bf1e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/192697
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-30 11:56:30 -06:00
|
|
|
sink = myprint1(z, 1, 2, 3) // ERROR "... argument escapes to heap$" "1 escapes to heap$" "2 escapes to heap$" "3 escapes to heap$"
|
2015-02-19 07:54:55 -07:00
|
|
|
}
|
|
|
|
|
2015-09-30 12:41:00 -06:00
|
|
|
func foo76(z *int) { // ERROR "z does not escape"
|
2019-09-12 11:18:03 -06:00
|
|
|
myprint(nil, z) // ERROR "... argument does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-09-30 12:41:00 -06:00
|
|
|
func foo76a(z *int) { // ERROR "z does not escape"
|
2019-09-12 11:18:03 -06:00
|
|
|
myprint1(nil, z) // ERROR "... argument does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func foo76b() {
|
2019-09-12 11:18:03 -06:00
|
|
|
myprint(nil, 1, 2, 3) // ERROR "1 does not escape" "2 does not escape" "3 does not escape" "... argument does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func foo76c() {
|
2019-09-12 11:18:03 -06:00
|
|
|
myprint1(nil, 1, 2, 3) // ERROR "1 does not escape" "2 does not escape" "3 does not escape" "... argument does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func foo76d() {
|
2019-09-12 11:18:03 -06:00
|
|
|
defer myprint(nil, 1, 2, 3) // ERROR "1 does not escape" "2 does not escape" "3 does not escape" "... argument does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func foo76e() {
|
2019-09-12 11:18:03 -06:00
|
|
|
defer myprint1(nil, 1, 2, 3) // ERROR "1 does not escape" "2 does not escape" "3 does not escape" "... argument does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func foo76f() {
|
|
|
|
for {
|
2011-08-28 10:05:00 -06:00
|
|
|
// TODO: This one really only escapes its scope, but we don't distinguish yet.
|
2015-02-19 12:00:11 -07:00
|
|
|
defer myprint(nil, 1, 2, 3) // ERROR "... argument escapes to heap$" "1 escapes to heap$" "2 escapes to heap$" "3 escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo76g() {
|
|
|
|
for {
|
2015-02-19 12:00:11 -07:00
|
|
|
defer myprint1(nil, 1, 2, 3) // ERROR "... argument escapes to heap$" "1 escapes to heap$" "2 escapes to heap$" "3 escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo77(z []interface{}) { // ERROR "z does not escape$"
|
2011-08-28 10:05:00 -06:00
|
|
|
myprint(nil, z...) // z does not escape
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo77a(z []interface{}) { // ERROR "z does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
myprint1(nil, z...)
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo77b(z []interface{}) { // ERROR "leaking param: z$"
|
cmd/gc: escape analysis to track flow of in to out parameters.
includes step 0: synthesize outparams, from 6600044
includes step 1,2: give outparams loopdepth 0 and verify unchanged results
generate esc:$mask tags, but still tie to sink if a param has mask != 0
from 6610054
adds final steps:
- have esccall generate n->escretval, a list of nodes the function results flow to
- use these in esccall and ORETURN/OAS2FUNC/and f(g())
- only tie parameters to sink if tag is absent, otherwise according to mask, tie them to escretval
R=rsc, bradfitz
CC=dave, gobot, golang-dev, iant, rsc
https://golang.org/cl/6741044
2012-10-29 06:38:21 -06:00
|
|
|
var ppi **interface{}
|
|
|
|
*ppi = myprint1(nil, z...)
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo77c(z []interface{}) { // ERROR "leaking param: z$"
|
cmd/compile: silence esc diagnostics about directiface OCONVIFACEs
In general, a conversion to interface type may require values to be
boxed, which in turn necessitates escape analysis to determine whether
the boxed representation can be stack allocated.
However, esc.go used to unconditionally print escape analysis
decisions about OCONVIFACE, even for conversions that don't require
boxing (e.g., pointers, channels, maps, functions).
For test compatibility with esc.go, escape.go similarly printed these
useless diagnostics. This CL removes the diagnostics, and updates test
expectations accordingly.
Change-Id: I97c57a4a08e44d265bba516c78426ff4f2bf1e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/192697
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-30 11:56:30 -06:00
|
|
|
sink = myprint1(nil, z...)
|
2015-02-19 07:54:55 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
func dotdotdot() {
|
2015-09-30 12:41:00 -06:00
|
|
|
i := 0
|
2019-09-12 11:18:03 -06:00
|
|
|
myprint(nil, &i) // ERROR "... argument does not escape$"
|
2015-02-19 07:54:55 -07:00
|
|
|
|
2015-09-30 12:41:00 -06:00
|
|
|
j := 0
|
2019-09-12 11:18:03 -06:00
|
|
|
myprint1(nil, &j) // ERROR "... argument does not escape$"
|
2015-02-19 07:54:55 -07:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo78(z int) *int { // ERROR "moved to heap: z$"
|
2019-04-01 12:58:33 -06:00
|
|
|
return &z
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo78a(z int) *int { // ERROR "moved to heap: z$"
|
2019-04-01 12:58:33 -06:00
|
|
|
y := &z
|
|
|
|
x := &y
|
2011-08-28 10:05:00 -06:00
|
|
|
return *x // really return y
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func foo79() *int {
|
2015-02-19 12:00:11 -07:00
|
|
|
return new(int) // ERROR "new\(int\) escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func foo80() *int {
|
|
|
|
var z *int
|
|
|
|
for {
|
2011-08-28 10:05:00 -06:00
|
|
|
// Really just escapes its scope but we don't distinguish
|
2015-02-19 12:00:11 -07:00
|
|
|
z = new(int) // ERROR "new\(int\) escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
_ = z
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo81() *int {
|
|
|
|
for {
|
2019-09-12 11:18:03 -06:00
|
|
|
z := new(int) // ERROR "new\(int\) does not escape$"
|
2011-08-24 11:07:08 -06:00
|
|
|
_ = z
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func tee(p *int) (x, y *int) { return p, p } // ERROR "leaking param: p to result x level=0$" "leaking param: p to result y level=0$"
|
2012-12-20 15:27:28 -07:00
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func noop(x, y *int) {} // ERROR "x does not escape$" "y does not escape$"
|
2012-12-20 15:27:28 -07:00
|
|
|
|
|
|
|
func foo82() {
|
cmd/compile: silence esc diagnostics about directiface OCONVIFACEs
In general, a conversion to interface type may require values to be
boxed, which in turn necessitates escape analysis to determine whether
the boxed representation can be stack allocated.
However, esc.go used to unconditionally print escape analysis
decisions about OCONVIFACE, even for conversions that don't require
boxing (e.g., pointers, channels, maps, functions).
For test compatibility with esc.go, escape.go similarly printed these
useless diagnostics. This CL removes the diagnostics, and updates test
expectations accordingly.
Change-Id: I97c57a4a08e44d265bba516c78426ff4f2bf1e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/192697
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-30 11:56:30 -06:00
|
|
|
var x, y, z int // ERROR "moved to heap: x$" "moved to heap: y$" "moved to heap: z$"
|
2019-04-01 12:58:33 -06:00
|
|
|
go noop(tee(&z))
|
|
|
|
go noop(&x, &y)
|
2012-12-20 15:27:28 -07:00
|
|
|
for {
|
cmd/compile: silence esc diagnostics about directiface OCONVIFACEs
In general, a conversion to interface type may require values to be
boxed, which in turn necessitates escape analysis to determine whether
the boxed representation can be stack allocated.
However, esc.go used to unconditionally print escape analysis
decisions about OCONVIFACE, even for conversions that don't require
boxing (e.g., pointers, channels, maps, functions).
For test compatibility with esc.go, escape.go similarly printed these
useless diagnostics. This CL removes the diagnostics, and updates test
expectations accordingly.
Change-Id: I97c57a4a08e44d265bba516c78426ff4f2bf1e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/192697
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-30 11:56:30 -06:00
|
|
|
var u, v, w int // ERROR "moved to heap: u$" "moved to heap: v$" "moved to heap: w$"
|
2019-04-01 12:58:33 -06:00
|
|
|
defer noop(tee(&u))
|
|
|
|
defer noop(&v, &w)
|
2012-12-20 15:27:28 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-08-24 11:07:08 -06:00
|
|
|
type Fooer interface {
|
|
|
|
Foo()
|
|
|
|
}
|
|
|
|
|
|
|
|
type LimitedFooer struct {
|
2011-08-28 10:05:00 -06:00
|
|
|
Fooer
|
|
|
|
N int64
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
cmd/compile: update escape analysis tests for newescape
The new escape analysis implementation tries to emit debugging
diagnostics that are compatible with the existing implementation, but
there's a handful of cases that are easier to handle by updating the
test expectations instead.
For regress tests that need updating, the original file is copied to
oldescapeXXX.go.go with -newescape=false added to the //errorcheck
line, while the file is updated in place with -newescape=true and new
test requirements.
Notable test changes:
1) escape_because.go looks for a lot of detailed internal debugging
messages that are fairly particular to how esc.go works and that I
haven't attempted to port over to escape.go yet.
2) There are a lot of "leaking param: x to result ~r1 level=-1"
messages for code like
func(p *int) *T { return &T{p} }
that were simply wrong. Here &T must be heap allocated unconditionally
(because it's being returned); and since p is stored into it, p
escapes unconditionally too. esc.go incorrectly reports that p escapes
conditionally only if the returned pointer escaped.
3) esc.go used to print each "leaking param" analysis result as it
discovered them, which could lead to redundant messages (e.g., that a
param leaks at level=0 and level=1). escape.go instead prints
everything at the end, once it knows the shortest path to each sink.
4) esc.go didn't precisely model direct-interface types, resulting in
some values unnecessarily escaping to the heap when stored into
non-escaping interface values.
5) For functions written in assembly, esc.go only printed "does not
escape" messages, whereas escape.go prints "does not escape" or
"leaking param" as appropriate, consistent with the behavior for
functions written in Go.
6) 12 tests included "BAD" annotations identifying cases where esc.go
was unnecessarily heap allocating something. These are all fixed by
escape.go.
Updates #23109.
Change-Id: Iabc9eb14c94c9cadde3b183478d1fd54f013502f
Reviewed-on: https://go-review.googlesource.com/c/go/+/170447
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
2019-04-02 15:44:13 -06:00
|
|
|
func LimitFooer(r Fooer, n int64) Fooer { // ERROR "leaking param: r$"
|
2015-02-19 12:00:11 -07:00
|
|
|
return &LimitedFooer{r, n} // ERROR "&LimitedFooer literal escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo90(x *int) map[*int]*int { // ERROR "leaking param: x$"
|
|
|
|
return map[*int]*int{nil: x} // ERROR "map\[\*int\]\*int literal escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo91(x *int) map[*int]*int { // ERROR "leaking param: x$"
|
|
|
|
return map[*int]*int{x: nil} // ERROR "map\[\*int\]\*int literal escapes to heap$"
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func foo92(x *int) [2]*int { // ERROR "leaking param: x to result ~r1 level=0$"
|
2011-08-28 10:05:00 -06:00
|
|
|
return [2]*int{x, nil}
|
2011-08-24 11:07:08 -06:00
|
|
|
}
|
|
|
|
|
2011-08-25 07:26:13 -06:00
|
|
|
// does not leak c
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo93(c chan *int) *int { // ERROR "c does not escape$"
|
2011-08-25 07:26:13 -06:00
|
|
|
for v := range c {
|
|
|
|
return v
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// does not leak m
|
2015-05-15 10:19:07 -06:00
|
|
|
func foo94(m map[*int]*int, b bool) *int { // ERROR "leaking param: m to result ~r2 level=1"
|
2011-08-25 07:26:13 -06:00
|
|
|
for k, v := range m {
|
|
|
|
if b {
|
|
|
|
return k
|
|
|
|
}
|
|
|
|
return v
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// does leak x
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo95(m map[*int]*int, x *int) { // ERROR "m does not escape$" "leaking param: x$"
|
2011-08-25 07:26:13 -06:00
|
|
|
m[x] = x
|
|
|
|
}
|
|
|
|
|
2015-05-15 10:19:07 -06:00
|
|
|
// does not leak m but does leak content
|
|
|
|
func foo96(m []*int) *int { // ERROR "leaking param: m to result ~r1 level=1"
|
2011-08-25 07:26:13 -06:00
|
|
|
return m[0]
|
|
|
|
}
|
|
|
|
|
|
|
|
// does leak m
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func foo97(m [1]*int) *int { // ERROR "leaking param: m to result ~r1 level=0$"
|
2011-08-25 07:26:13 -06:00
|
|
|
return m[0]
|
|
|
|
}
|
|
|
|
|
|
|
|
// does not leak m
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo98(m map[int]*int) *int { // ERROR "m does not escape$"
|
2011-08-25 07:26:13 -06:00
|
|
|
return m[0]
|
|
|
|
}
|
|
|
|
|
|
|
|
// does leak m
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func foo99(m *[1]*int) []*int { // ERROR "leaking param: m to result ~r1 level=0$"
|
2011-08-25 07:26:13 -06:00
|
|
|
return m[:]
|
|
|
|
}
|
|
|
|
|
|
|
|
// does not leak m
|
2015-05-15 10:19:07 -06:00
|
|
|
func foo100(m []*int) *int { // ERROR "leaking param: m to result ~r1 level=1"
|
2011-08-25 07:26:13 -06:00
|
|
|
for _, v := range m {
|
|
|
|
return v
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// does leak m
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func foo101(m [1]*int) *int { // ERROR "leaking param: m to result ~r1 level=0$"
|
2011-08-25 07:26:13 -06:00
|
|
|
for _, v := range m {
|
|
|
|
return v
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2011-08-28 10:05:00 -06:00
|
|
|
// does not leak m
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo101a(m [1]*int) *int { // ERROR "m does not escape$"
|
2015-02-19 12:00:11 -07:00
|
|
|
for i := range m { // ERROR "moved to heap: i$"
|
2019-04-01 12:58:33 -06:00
|
|
|
return &i
|
2011-08-28 10:05:00 -06:00
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2011-08-25 07:26:13 -06:00
|
|
|
// does leak x
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo102(m []*int, x *int) { // ERROR "m does not escape$" "leaking param: x$"
|
2011-08-25 07:26:13 -06:00
|
|
|
m[0] = x
|
|
|
|
}
|
|
|
|
|
|
|
|
// does not leak x
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo103(m [1]*int, x *int) { // ERROR "m does not escape$" "x does not escape$"
|
2011-08-25 07:26:13 -06:00
|
|
|
m[0] = x
|
|
|
|
}
|
|
|
|
|
|
|
|
var y []*int
|
|
|
|
|
2015-06-24 15:31:57 -06:00
|
|
|
// does not leak x but does leak content
|
|
|
|
func foo104(x []*int) { // ERROR "leaking param content: x"
|
2011-08-25 07:26:13 -06:00
|
|
|
copy(y, x)
|
|
|
|
}
|
|
|
|
|
2015-05-15 10:19:07 -06:00
|
|
|
// does not leak x but does leak content
|
|
|
|
func foo105(x []*int) { // ERROR "leaking param content: x"
|
2011-08-25 07:26:13 -06:00
|
|
|
_ = append(y, x...)
|
|
|
|
}
|
|
|
|
|
|
|
|
// does leak x
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo106(x *int) { // ERROR "leaking param: x$"
|
2011-08-25 07:26:13 -06:00
|
|
|
_ = append(y, x)
|
|
|
|
}
|
2011-08-28 10:05:00 -06:00
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo107(x *int) map[*int]*int { // ERROR "leaking param: x$"
|
|
|
|
return map[*int]*int{x: nil} // ERROR "map\[\*int\]\*int literal escapes to heap$"
|
2011-08-28 10:05:00 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo108(x *int) map[*int]*int { // ERROR "leaking param: x$"
|
|
|
|
return map[*int]*int{nil: x} // ERROR "map\[\*int\]\*int literal escapes to heap$"
|
2011-08-28 10:05:00 -06:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo109(x *int) *int { // ERROR "leaking param: x$"
|
2019-09-12 11:18:03 -06:00
|
|
|
m := map[*int]*int{x: nil} // ERROR "map\[\*int\]\*int literal does not escape$"
|
2011-08-28 10:05:00 -06:00
|
|
|
for k, _ := range m {
|
|
|
|
return k
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo110(x *int) *int { // ERROR "leaking param: x$"
|
2019-09-12 11:18:03 -06:00
|
|
|
m := map[*int]*int{nil: x} // ERROR "map\[\*int\]\*int literal does not escape$"
|
2011-08-28 10:05:00 -06:00
|
|
|
return m[nil]
|
|
|
|
}
|
|
|
|
|
2015-05-15 10:19:07 -06:00
|
|
|
func foo111(x *int) *int { // ERROR "leaking param: x to result ~r1 level=0"
|
2019-09-12 11:18:03 -06:00
|
|
|
m := []*int{x} // ERROR "\[\]\*int literal does not escape$"
|
2011-08-28 10:05:00 -06:00
|
|
|
return m[0]
|
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func foo112(x *int) *int { // ERROR "leaking param: x to result ~r1 level=0$"
|
2011-08-28 10:05:00 -06:00
|
|
|
m := [1]*int{x}
|
|
|
|
return m[0]
|
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func foo113(x *int) *int { // ERROR "leaking param: x to result ~r1 level=0$"
|
2011-08-28 10:05:00 -06:00
|
|
|
m := Bar{ii: x}
|
|
|
|
return m.ii
|
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func foo114(x *int) *int { // ERROR "leaking param: x to result ~r1 level=0$"
|
2019-09-12 11:18:03 -06:00
|
|
|
m := &Bar{ii: x} // ERROR "&Bar literal does not escape$"
|
2011-08-28 10:05:00 -06:00
|
|
|
return m.ii
|
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func foo115(x *int) *int { // ERROR "leaking param: x to result ~r1 level=0$"
|
2011-08-28 10:05:00 -06:00
|
|
|
return (*int)(unsafe.Pointer(uintptr(unsafe.Pointer(x)) + 1))
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo116(b bool) *int {
|
|
|
|
if b {
|
cmd/compile: silence esc diagnostics about directiface OCONVIFACEs
In general, a conversion to interface type may require values to be
boxed, which in turn necessitates escape analysis to determine whether
the boxed representation can be stack allocated.
However, esc.go used to unconditionally print escape analysis
decisions about OCONVIFACE, even for conversions that don't require
boxing (e.g., pointers, channels, maps, functions).
For test compatibility with esc.go, escape.go similarly printed these
useless diagnostics. This CL removes the diagnostics, and updates test
expectations accordingly.
Change-Id: I97c57a4a08e44d265bba516c78426ff4f2bf1e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/192697
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-30 11:56:30 -06:00
|
|
|
x := 1 // ERROR "moved to heap: x$"
|
2019-04-01 12:58:33 -06:00
|
|
|
return &x
|
2011-08-28 10:05:00 -06:00
|
|
|
} else {
|
cmd/compile: silence esc diagnostics about directiface OCONVIFACEs
In general, a conversion to interface type may require values to be
boxed, which in turn necessitates escape analysis to determine whether
the boxed representation can be stack allocated.
However, esc.go used to unconditionally print escape analysis
decisions about OCONVIFACE, even for conversions that don't require
boxing (e.g., pointers, channels, maps, functions).
For test compatibility with esc.go, escape.go similarly printed these
useless diagnostics. This CL removes the diagnostics, and updates test
expectations accordingly.
Change-Id: I97c57a4a08e44d265bba516c78426ff4f2bf1e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/192697
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-30 11:56:30 -06:00
|
|
|
y := 1 // ERROR "moved to heap: y$"
|
2019-04-01 12:58:33 -06:00
|
|
|
return &y
|
2011-08-28 10:05:00 -06:00
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo117(unknown func(interface{})) { // ERROR "unknown does not escape$"
|
cmd/compile: silence esc diagnostics about directiface OCONVIFACEs
In general, a conversion to interface type may require values to be
boxed, which in turn necessitates escape analysis to determine whether
the boxed representation can be stack allocated.
However, esc.go used to unconditionally print escape analysis
decisions about OCONVIFACE, even for conversions that don't require
boxing (e.g., pointers, channels, maps, functions).
For test compatibility with esc.go, escape.go similarly printed these
useless diagnostics. This CL removes the diagnostics, and updates test
expectations accordingly.
Change-Id: I97c57a4a08e44d265bba516c78426ff4f2bf1e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/192697
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-30 11:56:30 -06:00
|
|
|
x := 1 // ERROR "moved to heap: x$"
|
|
|
|
unknown(&x)
|
2011-08-28 10:05:00 -06:00
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo118(unknown func(*int)) { // ERROR "unknown does not escape$"
|
cmd/compile: silence esc diagnostics about directiface OCONVIFACEs
In general, a conversion to interface type may require values to be
boxed, which in turn necessitates escape analysis to determine whether
the boxed representation can be stack allocated.
However, esc.go used to unconditionally print escape analysis
decisions about OCONVIFACE, even for conversions that don't require
boxing (e.g., pointers, channels, maps, functions).
For test compatibility with esc.go, escape.go similarly printed these
useless diagnostics. This CL removes the diagnostics, and updates test
expectations accordingly.
Change-Id: I97c57a4a08e44d265bba516c78426ff4f2bf1e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/192697
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-30 11:56:30 -06:00
|
|
|
x := 1 // ERROR "moved to heap: x$"
|
2019-04-01 12:58:33 -06:00
|
|
|
unknown(&x)
|
2011-08-28 10:05:00 -06:00
|
|
|
}
|
2011-08-28 21:29:34 -06:00
|
|
|
|
|
|
|
func external(*int)
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo119(x *int) { // ERROR "leaking param: x$"
|
2011-08-28 21:29:34 -06:00
|
|
|
external(x)
|
|
|
|
}
|
2011-09-01 11:44:46 -06:00
|
|
|
|
|
|
|
func foo120() {
|
|
|
|
// formerly exponential time analysis
|
|
|
|
L1:
|
|
|
|
L2:
|
|
|
|
L3:
|
|
|
|
L4:
|
|
|
|
L5:
|
|
|
|
L6:
|
|
|
|
L7:
|
|
|
|
L8:
|
|
|
|
L9:
|
|
|
|
L10:
|
|
|
|
L11:
|
|
|
|
L12:
|
|
|
|
L13:
|
|
|
|
L14:
|
|
|
|
L15:
|
|
|
|
L16:
|
|
|
|
L17:
|
|
|
|
L18:
|
|
|
|
L19:
|
|
|
|
L20:
|
|
|
|
L21:
|
|
|
|
L22:
|
|
|
|
L23:
|
|
|
|
L24:
|
|
|
|
L25:
|
|
|
|
L26:
|
|
|
|
L27:
|
|
|
|
L28:
|
|
|
|
L29:
|
|
|
|
L30:
|
|
|
|
L31:
|
|
|
|
L32:
|
|
|
|
L33:
|
|
|
|
L34:
|
|
|
|
L35:
|
|
|
|
L36:
|
|
|
|
L37:
|
|
|
|
L38:
|
|
|
|
L39:
|
|
|
|
L40:
|
|
|
|
L41:
|
|
|
|
L42:
|
|
|
|
L43:
|
|
|
|
L44:
|
|
|
|
L45:
|
|
|
|
L46:
|
|
|
|
L47:
|
|
|
|
L48:
|
|
|
|
L49:
|
|
|
|
L50:
|
|
|
|
L51:
|
|
|
|
L52:
|
|
|
|
L53:
|
|
|
|
L54:
|
|
|
|
L55:
|
|
|
|
L56:
|
|
|
|
L57:
|
|
|
|
L58:
|
|
|
|
L59:
|
|
|
|
L60:
|
|
|
|
L61:
|
|
|
|
L62:
|
|
|
|
L63:
|
|
|
|
L64:
|
|
|
|
L65:
|
|
|
|
L66:
|
|
|
|
L67:
|
|
|
|
L68:
|
|
|
|
L69:
|
|
|
|
L70:
|
|
|
|
L71:
|
|
|
|
L72:
|
|
|
|
L73:
|
|
|
|
L74:
|
|
|
|
L75:
|
|
|
|
L76:
|
|
|
|
L77:
|
|
|
|
L78:
|
|
|
|
L79:
|
|
|
|
L80:
|
|
|
|
L81:
|
|
|
|
L82:
|
|
|
|
L83:
|
|
|
|
L84:
|
|
|
|
L85:
|
|
|
|
L86:
|
|
|
|
L87:
|
|
|
|
L88:
|
|
|
|
L89:
|
|
|
|
L90:
|
|
|
|
L91:
|
|
|
|
L92:
|
|
|
|
L93:
|
|
|
|
L94:
|
|
|
|
L95:
|
|
|
|
L96:
|
|
|
|
L97:
|
|
|
|
L98:
|
|
|
|
L99:
|
|
|
|
L100:
|
|
|
|
// use the labels to silence compiler errors
|
|
|
|
goto L1
|
|
|
|
goto L2
|
|
|
|
goto L3
|
|
|
|
goto L4
|
|
|
|
goto L5
|
|
|
|
goto L6
|
|
|
|
goto L7
|
|
|
|
goto L8
|
|
|
|
goto L9
|
|
|
|
goto L10
|
|
|
|
goto L11
|
|
|
|
goto L12
|
|
|
|
goto L13
|
|
|
|
goto L14
|
|
|
|
goto L15
|
|
|
|
goto L16
|
|
|
|
goto L17
|
|
|
|
goto L18
|
|
|
|
goto L19
|
|
|
|
goto L20
|
|
|
|
goto L21
|
|
|
|
goto L22
|
|
|
|
goto L23
|
|
|
|
goto L24
|
|
|
|
goto L25
|
|
|
|
goto L26
|
|
|
|
goto L27
|
|
|
|
goto L28
|
|
|
|
goto L29
|
|
|
|
goto L30
|
|
|
|
goto L31
|
|
|
|
goto L32
|
|
|
|
goto L33
|
|
|
|
goto L34
|
|
|
|
goto L35
|
|
|
|
goto L36
|
|
|
|
goto L37
|
|
|
|
goto L38
|
|
|
|
goto L39
|
|
|
|
goto L40
|
|
|
|
goto L41
|
|
|
|
goto L42
|
|
|
|
goto L43
|
|
|
|
goto L44
|
|
|
|
goto L45
|
|
|
|
goto L46
|
|
|
|
goto L47
|
|
|
|
goto L48
|
|
|
|
goto L49
|
|
|
|
goto L50
|
|
|
|
goto L51
|
|
|
|
goto L52
|
|
|
|
goto L53
|
|
|
|
goto L54
|
|
|
|
goto L55
|
|
|
|
goto L56
|
|
|
|
goto L57
|
|
|
|
goto L58
|
|
|
|
goto L59
|
|
|
|
goto L60
|
|
|
|
goto L61
|
|
|
|
goto L62
|
|
|
|
goto L63
|
|
|
|
goto L64
|
|
|
|
goto L65
|
|
|
|
goto L66
|
|
|
|
goto L67
|
|
|
|
goto L68
|
|
|
|
goto L69
|
|
|
|
goto L70
|
|
|
|
goto L71
|
|
|
|
goto L72
|
|
|
|
goto L73
|
|
|
|
goto L74
|
|
|
|
goto L75
|
|
|
|
goto L76
|
|
|
|
goto L77
|
|
|
|
goto L78
|
|
|
|
goto L79
|
|
|
|
goto L80
|
|
|
|
goto L81
|
|
|
|
goto L82
|
|
|
|
goto L83
|
|
|
|
goto L84
|
|
|
|
goto L85
|
|
|
|
goto L86
|
|
|
|
goto L87
|
|
|
|
goto L88
|
|
|
|
goto L89
|
|
|
|
goto L90
|
|
|
|
goto L91
|
|
|
|
goto L92
|
|
|
|
goto L93
|
|
|
|
goto L94
|
|
|
|
goto L95
|
|
|
|
goto L96
|
|
|
|
goto L97
|
|
|
|
goto L98
|
|
|
|
goto L99
|
|
|
|
goto L100
|
|
|
|
}
|
2011-11-01 09:02:43 -06:00
|
|
|
|
|
|
|
func foo121() {
|
|
|
|
for i := 0; i < 10; i++ {
|
2015-02-19 12:00:11 -07:00
|
|
|
defer myprint(nil, i) // ERROR "... argument escapes to heap$" "i escapes to heap$"
|
|
|
|
go myprint(nil, i) // ERROR "... argument escapes to heap$" "i escapes to heap$"
|
2011-11-01 09:02:43 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// same as foo121 but check across import
|
|
|
|
func foo121b() {
|
|
|
|
for i := 0; i < 10; i++ {
|
2015-02-19 12:00:11 -07:00
|
|
|
defer fmt.Printf("%d", i) // ERROR "... argument escapes to heap$" "i escapes to heap$"
|
|
|
|
go fmt.Printf("%d", i) // ERROR "... argument escapes to heap$" "i escapes to heap$"
|
2011-11-01 09:02:43 -06:00
|
|
|
}
|
|
|
|
}
|
2011-12-15 09:35:59 -07:00
|
|
|
|
|
|
|
// a harmless forward jump
|
|
|
|
func foo122() {
|
|
|
|
var i *int
|
|
|
|
|
|
|
|
goto L1
|
|
|
|
L1:
|
2019-09-12 11:18:03 -06:00
|
|
|
i = new(int) // ERROR "new\(int\) does not escape$"
|
2011-12-15 09:35:59 -07:00
|
|
|
_ = i
|
|
|
|
}
|
|
|
|
|
|
|
|
// a backward jump, increases loopdepth
|
|
|
|
func foo123() {
|
|
|
|
var i *int
|
|
|
|
|
|
|
|
L1:
|
2015-02-19 12:00:11 -07:00
|
|
|
i = new(int) // ERROR "new\(int\) escapes to heap$"
|
2011-12-15 09:35:59 -07:00
|
|
|
|
|
|
|
goto L1
|
|
|
|
_ = i
|
2012-01-12 04:08:40 -07:00
|
|
|
}
|
2012-04-23 13:39:01 -06:00
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo124(x **int) { // ERROR "x does not escape$"
|
2015-02-19 12:00:11 -07:00
|
|
|
var i int // ERROR "moved to heap: i$"
|
2019-04-01 12:58:33 -06:00
|
|
|
p := &i
|
2019-09-12 11:18:03 -06:00
|
|
|
func() { // ERROR "func literal does not escape$"
|
2019-04-01 15:01:58 -06:00
|
|
|
*x = p
|
2012-04-23 13:39:01 -06:00
|
|
|
}()
|
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo125(ch chan *int) { // ERROR "ch does not escape$"
|
2015-02-19 12:00:11 -07:00
|
|
|
var i int // ERROR "moved to heap: i$"
|
2019-04-01 12:58:33 -06:00
|
|
|
p := &i
|
2019-09-12 11:18:03 -06:00
|
|
|
func() { // ERROR "func literal does not escape$"
|
2019-04-01 15:01:58 -06:00
|
|
|
ch <- p
|
2012-04-23 13:39:01 -06:00
|
|
|
}()
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo126() {
|
2012-12-20 15:27:28 -07:00
|
|
|
var px *int // loopdepth 0
|
2012-04-23 13:39:01 -06:00
|
|
|
for {
|
|
|
|
// loopdepth 1
|
2015-02-19 12:00:11 -07:00
|
|
|
var i int // ERROR "moved to heap: i$"
|
2019-09-12 11:18:03 -06:00
|
|
|
func() { // ERROR "func literal does not escape$"
|
2019-04-01 15:01:58 -06:00
|
|
|
px = &i
|
2012-04-23 13:39:01 -06:00
|
|
|
}()
|
|
|
|
}
|
2013-09-17 16:24:54 -06:00
|
|
|
_ = px
|
2012-04-23 13:39:01 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
var px *int
|
|
|
|
|
|
|
|
func foo127() {
|
2015-02-19 12:00:11 -07:00
|
|
|
var i int // ERROR "moved to heap: i$"
|
2019-04-01 12:58:33 -06:00
|
|
|
p := &i
|
2012-04-23 13:39:01 -06:00
|
|
|
q := p
|
|
|
|
px = q
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo128() {
|
|
|
|
var i int
|
2019-04-01 12:58:33 -06:00
|
|
|
p := &i
|
2012-04-23 13:39:01 -06:00
|
|
|
q := p
|
|
|
|
_ = q
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo129() {
|
2015-02-19 12:00:11 -07:00
|
|
|
var i int // ERROR "moved to heap: i$"
|
2019-04-01 12:58:33 -06:00
|
|
|
p := &i
|
2019-09-12 11:18:03 -06:00
|
|
|
func() { // ERROR "func literal does not escape$"
|
2019-04-01 15:01:58 -06:00
|
|
|
q := p
|
2019-09-12 11:18:03 -06:00
|
|
|
func() { // ERROR "func literal does not escape$"
|
2019-04-01 15:01:58 -06:00
|
|
|
r := q
|
2012-04-23 13:39:01 -06:00
|
|
|
px = r
|
|
|
|
}()
|
|
|
|
}()
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo130() {
|
|
|
|
for {
|
2015-02-19 12:00:11 -07:00
|
|
|
var i int // ERROR "moved to heap: i$"
|
2019-09-12 11:18:03 -06:00
|
|
|
func() { // ERROR "func literal does not escape$"
|
2019-04-01 15:01:58 -06:00
|
|
|
px = &i
|
2012-04-23 13:39:01 -06:00
|
|
|
}()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo131() {
|
2015-02-19 12:00:11 -07:00
|
|
|
var i int // ERROR "moved to heap: i$"
|
2019-09-12 11:18:03 -06:00
|
|
|
func() { // ERROR "func literal does not escape$"
|
2019-04-01 15:01:58 -06:00
|
|
|
px = &i
|
2012-04-23 13:39:01 -06:00
|
|
|
}()
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo132() {
|
2015-02-19 12:00:11 -07:00
|
|
|
var i int // ERROR "moved to heap: i$"
|
|
|
|
go func() { // ERROR "func literal escapes to heap$"
|
2019-04-01 15:01:58 -06:00
|
|
|
px = &i
|
2012-04-23 13:39:01 -06:00
|
|
|
}()
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo133() {
|
2015-02-19 12:00:11 -07:00
|
|
|
var i int // ERROR "moved to heap: i$"
|
2019-09-12 11:18:03 -06:00
|
|
|
defer func() { // ERROR "func literal does not escape$"
|
2019-04-01 15:01:58 -06:00
|
|
|
px = &i
|
2012-04-23 13:39:01 -06:00
|
|
|
}()
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo134() {
|
|
|
|
var i int
|
2019-04-01 12:58:33 -06:00
|
|
|
p := &i
|
2019-09-12 11:18:03 -06:00
|
|
|
func() { // ERROR "func literal does not escape$"
|
2012-04-23 13:39:01 -06:00
|
|
|
q := p
|
2019-09-12 11:18:03 -06:00
|
|
|
func() { // ERROR "func literal does not escape$"
|
2012-04-23 13:39:01 -06:00
|
|
|
r := q
|
|
|
|
_ = r
|
|
|
|
}()
|
|
|
|
}()
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo135() {
|
cmd/compile: silence esc diagnostics about directiface OCONVIFACEs
In general, a conversion to interface type may require values to be
boxed, which in turn necessitates escape analysis to determine whether
the boxed representation can be stack allocated.
However, esc.go used to unconditionally print escape analysis
decisions about OCONVIFACE, even for conversions that don't require
boxing (e.g., pointers, channels, maps, functions).
For test compatibility with esc.go, escape.go similarly printed these
useless diagnostics. This CL removes the diagnostics, and updates test
expectations accordingly.
Change-Id: I97c57a4a08e44d265bba516c78426ff4f2bf1e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/192697
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-30 11:56:30 -06:00
|
|
|
var i int // ERROR "moved to heap: i$"
|
2019-04-01 12:58:33 -06:00
|
|
|
p := &i
|
2015-02-19 12:00:11 -07:00
|
|
|
go func() { // ERROR "func literal escapes to heap$"
|
2015-01-19 12:59:58 -07:00
|
|
|
q := p
|
2019-09-12 11:18:03 -06:00
|
|
|
func() { // ERROR "func literal does not escape$"
|
2012-04-23 13:39:01 -06:00
|
|
|
r := q
|
|
|
|
_ = r
|
|
|
|
}()
|
|
|
|
}()
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo136() {
|
cmd/compile: silence esc diagnostics about directiface OCONVIFACEs
In general, a conversion to interface type may require values to be
boxed, which in turn necessitates escape analysis to determine whether
the boxed representation can be stack allocated.
However, esc.go used to unconditionally print escape analysis
decisions about OCONVIFACE, even for conversions that don't require
boxing (e.g., pointers, channels, maps, functions).
For test compatibility with esc.go, escape.go similarly printed these
useless diagnostics. This CL removes the diagnostics, and updates test
expectations accordingly.
Change-Id: I97c57a4a08e44d265bba516c78426ff4f2bf1e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/192697
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-30 11:56:30 -06:00
|
|
|
var i int // ERROR "moved to heap: i$"
|
2019-04-01 12:58:33 -06:00
|
|
|
p := &i
|
2015-02-19 12:00:11 -07:00
|
|
|
go func() { // ERROR "func literal escapes to heap$"
|
2019-04-01 15:01:58 -06:00
|
|
|
q := p
|
2019-09-12 11:18:03 -06:00
|
|
|
func() { // ERROR "func literal does not escape$"
|
2019-04-01 15:01:58 -06:00
|
|
|
r := q
|
2012-04-23 13:39:01 -06:00
|
|
|
px = r
|
|
|
|
}()
|
|
|
|
}()
|
|
|
|
}
|
|
|
|
|
|
|
|
func foo137() {
|
2015-02-19 12:00:11 -07:00
|
|
|
var i int // ERROR "moved to heap: i$"
|
2019-04-01 12:58:33 -06:00
|
|
|
p := &i
|
2019-09-12 11:18:03 -06:00
|
|
|
func() { // ERROR "func literal does not escape$"
|
2019-04-01 15:01:58 -06:00
|
|
|
q := p
|
2015-02-19 12:00:11 -07:00
|
|
|
go func() { // ERROR "func literal escapes to heap$"
|
2015-01-19 12:59:58 -07:00
|
|
|
r := q
|
2012-04-23 13:39:01 -06:00
|
|
|
_ = r
|
|
|
|
}()
|
|
|
|
}()
|
|
|
|
}
|
2012-09-24 13:53:12 -06:00
|
|
|
|
|
|
|
func foo138() *byte {
|
|
|
|
type T struct {
|
|
|
|
x [1]byte
|
|
|
|
}
|
cmd/compile: silence esc diagnostics about directiface OCONVIFACEs
In general, a conversion to interface type may require values to be
boxed, which in turn necessitates escape analysis to determine whether
the boxed representation can be stack allocated.
However, esc.go used to unconditionally print escape analysis
decisions about OCONVIFACE, even for conversions that don't require
boxing (e.g., pointers, channels, maps, functions).
For test compatibility with esc.go, escape.go similarly printed these
useless diagnostics. This CL removes the diagnostics, and updates test
expectations accordingly.
Change-Id: I97c57a4a08e44d265bba516c78426ff4f2bf1e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/192697
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-30 11:56:30 -06:00
|
|
|
t := new(T) // ERROR "new\(T\) escapes to heap$"
|
2019-04-01 12:58:33 -06:00
|
|
|
return &t.x[0]
|
2012-09-24 13:53:12 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func foo139() *byte {
|
|
|
|
type T struct {
|
|
|
|
x struct {
|
|
|
|
y byte
|
|
|
|
}
|
|
|
|
}
|
cmd/compile: silence esc diagnostics about directiface OCONVIFACEs
In general, a conversion to interface type may require values to be
boxed, which in turn necessitates escape analysis to determine whether
the boxed representation can be stack allocated.
However, esc.go used to unconditionally print escape analysis
decisions about OCONVIFACE, even for conversions that don't require
boxing (e.g., pointers, channels, maps, functions).
For test compatibility with esc.go, escape.go similarly printed these
useless diagnostics. This CL removes the diagnostics, and updates test
expectations accordingly.
Change-Id: I97c57a4a08e44d265bba516c78426ff4f2bf1e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/192697
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-30 11:56:30 -06:00
|
|
|
t := new(T) // ERROR "new\(T\) escapes to heap$"
|
2019-04-01 12:58:33 -06:00
|
|
|
return &t.x.y
|
2012-09-24 13:53:12 -06:00
|
|
|
}
|
2013-02-04 20:48:31 -07:00
|
|
|
|
|
|
|
// issue 4751
|
|
|
|
func foo140() interface{} {
|
|
|
|
type T struct {
|
|
|
|
X string
|
|
|
|
}
|
|
|
|
type U struct {
|
|
|
|
X string
|
|
|
|
T *T
|
|
|
|
}
|
2015-02-19 12:00:11 -07:00
|
|
|
t := &T{} // ERROR "&T literal escapes to heap$"
|
|
|
|
return U{ // ERROR "U literal escapes to heap$"
|
2013-02-04 20:48:31 -07:00
|
|
|
X: t.X,
|
|
|
|
T: t,
|
|
|
|
}
|
|
|
|
}
|
2013-02-05 05:00:38 -07:00
|
|
|
|
|
|
|
//go:noescape
|
|
|
|
|
|
|
|
func F1([]byte)
|
|
|
|
|
|
|
|
func F2([]byte)
|
|
|
|
|
|
|
|
//go:noescape
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func F3(x []byte) // ERROR "x does not escape$"
|
2013-02-05 05:00:38 -07:00
|
|
|
|
cmd/compile: update escape analysis tests for newescape
The new escape analysis implementation tries to emit debugging
diagnostics that are compatible with the existing implementation, but
there's a handful of cases that are easier to handle by updating the
test expectations instead.
For regress tests that need updating, the original file is copied to
oldescapeXXX.go.go with -newescape=false added to the //errorcheck
line, while the file is updated in place with -newescape=true and new
test requirements.
Notable test changes:
1) escape_because.go looks for a lot of detailed internal debugging
messages that are fairly particular to how esc.go works and that I
haven't attempted to port over to escape.go yet.
2) There are a lot of "leaking param: x to result ~r1 level=-1"
messages for code like
func(p *int) *T { return &T{p} }
that were simply wrong. Here &T must be heap allocated unconditionally
(because it's being returned); and since p is stored into it, p
escapes unconditionally too. esc.go incorrectly reports that p escapes
conditionally only if the returned pointer escaped.
3) esc.go used to print each "leaking param" analysis result as it
discovered them, which could lead to redundant messages (e.g., that a
param leaks at level=0 and level=1). escape.go instead prints
everything at the end, once it knows the shortest path to each sink.
4) esc.go didn't precisely model direct-interface types, resulting in
some values unnecessarily escaping to the heap when stored into
non-escaping interface values.
5) For functions written in assembly, esc.go only printed "does not
escape" messages, whereas escape.go prints "does not escape" or
"leaking param" as appropriate, consistent with the behavior for
functions written in Go.
6) 12 tests included "BAD" annotations identifying cases where esc.go
was unnecessarily heap allocating something. These are all fixed by
escape.go.
Updates #23109.
Change-Id: Iabc9eb14c94c9cadde3b183478d1fd54f013502f
Reviewed-on: https://go-review.googlesource.com/c/go/+/170447
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
2019-04-02 15:44:13 -06:00
|
|
|
func F4(x []byte) // ERROR "leaking param: x$"
|
2013-02-05 05:00:38 -07:00
|
|
|
|
|
|
|
func G() {
|
|
|
|
var buf1 [10]byte
|
2019-04-01 12:58:33 -06:00
|
|
|
F1(buf1[:])
|
2014-05-09 13:40:45 -06:00
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
var buf2 [10]byte // ERROR "moved to heap: buf2$"
|
2019-04-01 12:58:33 -06:00
|
|
|
F2(buf2[:])
|
2013-02-05 05:00:38 -07:00
|
|
|
|
|
|
|
var buf3 [10]byte
|
2019-04-01 12:58:33 -06:00
|
|
|
F3(buf3[:])
|
2014-05-09 13:40:45 -06:00
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
var buf4 [10]byte // ERROR "moved to heap: buf4$"
|
2019-04-01 12:58:33 -06:00
|
|
|
F4(buf4[:])
|
2013-02-05 05:00:38 -07:00
|
|
|
}
|
2013-03-20 21:53:27 -06:00
|
|
|
|
|
|
|
type Tm struct {
|
|
|
|
x int
|
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func (t *Tm) M() { // ERROR "t does not escape$"
|
2013-03-20 21:53:27 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func foo141() {
|
|
|
|
var f func()
|
2014-05-09 13:40:45 -06:00
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
t := new(Tm) // ERROR "new\(Tm\) escapes to heap$"
|
2019-09-12 11:18:03 -06:00
|
|
|
f = t.M // ERROR "t.M does not escape$"
|
2013-03-20 21:53:27 -06:00
|
|
|
_ = f
|
|
|
|
}
|
|
|
|
|
|
|
|
var gf func()
|
|
|
|
|
|
|
|
func foo142() {
|
2015-02-19 12:00:11 -07:00
|
|
|
t := new(Tm) // ERROR "new\(Tm\) escapes to heap$"
|
|
|
|
gf = t.M // ERROR "t.M escapes to heap$"
|
2013-03-20 21:53:27 -06:00
|
|
|
}
|
2013-05-22 14:45:38 -06:00
|
|
|
|
|
|
|
// issue 3888.
|
|
|
|
func foo143() {
|
|
|
|
for i := 0; i < 1000; i++ {
|
2019-09-12 11:18:03 -06:00
|
|
|
func() { // ERROR "func literal does not escape$"
|
2013-05-22 14:45:38 -06:00
|
|
|
for i := 0; i < 1; i++ {
|
|
|
|
var t Tm
|
2019-04-01 12:58:33 -06:00
|
|
|
t.M()
|
2013-05-22 14:45:38 -06:00
|
|
|
}
|
|
|
|
}()
|
|
|
|
}
|
|
|
|
}
|
2013-06-25 15:28:49 -06:00
|
|
|
|
|
|
|
// issue 5773
|
|
|
|
// Check that annotations take effect regardless of whether they
|
|
|
|
// are before or after the use in the source code.
|
|
|
|
|
|
|
|
//go:noescape
|
|
|
|
|
|
|
|
func foo144a(*int)
|
|
|
|
|
|
|
|
func foo144() {
|
|
|
|
var x int
|
2019-04-01 12:58:33 -06:00
|
|
|
foo144a(&x)
|
2013-06-25 15:28:49 -06:00
|
|
|
var y int
|
2019-04-01 12:58:33 -06:00
|
|
|
foo144b(&y)
|
2013-06-25 15:28:49 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
//go:noescape
|
|
|
|
|
|
|
|
func foo144b(*int)
|
2014-02-13 12:04:43 -07:00
|
|
|
|
|
|
|
// issue 7313: for loop init should not be treated as "in loop"
|
|
|
|
|
|
|
|
type List struct {
|
|
|
|
Next *List
|
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo145(l List) { // ERROR "l does not escape$"
|
2014-02-13 12:04:43 -07:00
|
|
|
var p *List
|
2019-04-01 12:58:33 -06:00
|
|
|
for p = &l; p.Next != nil; p = p.Next {
|
2014-02-13 12:04:43 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo146(l List) { // ERROR "l does not escape$"
|
2014-02-13 12:04:43 -07:00
|
|
|
var p *List
|
2019-04-01 12:58:33 -06:00
|
|
|
p = &l
|
2014-02-13 12:04:43 -07:00
|
|
|
for ; p.Next != nil; p = p.Next {
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo147(l List) { // ERROR "l does not escape$"
|
2014-02-13 12:04:43 -07:00
|
|
|
var p *List
|
2019-04-01 12:58:33 -06:00
|
|
|
p = &l
|
2014-02-13 12:04:43 -07:00
|
|
|
for p.Next != nil {
|
|
|
|
p = p.Next
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo148(l List) { // ERROR "l does not escape$"
|
2019-04-01 12:58:33 -06:00
|
|
|
for p := &l; p.Next != nil; p = p.Next {
|
2014-02-13 12:04:43 -07:00
|
|
|
}
|
|
|
|
}
|
2014-02-13 17:59:09 -07:00
|
|
|
|
|
|
|
// related: address of variable should have depth of variable, not of loop
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo149(l List) { // ERROR "l does not escape$"
|
2014-02-13 17:59:09 -07:00
|
|
|
var p *List
|
|
|
|
for {
|
2019-04-01 12:58:33 -06:00
|
|
|
for p = &l; p.Next != nil; p = p.Next {
|
2014-02-13 17:59:09 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2014-05-09 13:40:45 -06:00
|
|
|
|
|
|
|
// issue 7934: missed ... if element type had no pointers
|
|
|
|
|
|
|
|
var save150 []byte
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo150(x ...byte) { // ERROR "leaking param: x$"
|
2014-05-09 13:40:45 -06:00
|
|
|
save150 = x
|
|
|
|
}
|
|
|
|
|
|
|
|
func bar150() {
|
2015-02-19 12:00:11 -07:00
|
|
|
foo150(1, 2, 3) // ERROR "... argument escapes to heap$"
|
2014-05-09 13:40:45 -06:00
|
|
|
}
|
2014-05-12 12:45:05 -06:00
|
|
|
|
|
|
|
// issue 7931: bad handling of slice of array
|
|
|
|
|
|
|
|
var save151 *int
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func foo151(x *int) { // ERROR "leaking param: x$"
|
2014-05-12 12:45:05 -06:00
|
|
|
save151 = x
|
|
|
|
}
|
|
|
|
|
|
|
|
func bar151() {
|
2015-02-19 12:00:11 -07:00
|
|
|
var a [64]int // ERROR "moved to heap: a$"
|
2014-05-12 12:45:05 -06:00
|
|
|
a[4] = 101
|
2019-04-01 12:58:33 -06:00
|
|
|
foo151(&(&a)[4:8][0])
|
2014-05-12 12:45:05 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func bar151b() {
|
cmd/compile: silence esc diagnostics about directiface OCONVIFACEs
In general, a conversion to interface type may require values to be
boxed, which in turn necessitates escape analysis to determine whether
the boxed representation can be stack allocated.
However, esc.go used to unconditionally print escape analysis
decisions about OCONVIFACE, even for conversions that don't require
boxing (e.g., pointers, channels, maps, functions).
For test compatibility with esc.go, escape.go similarly printed these
useless diagnostics. This CL removes the diagnostics, and updates test
expectations accordingly.
Change-Id: I97c57a4a08e44d265bba516c78426ff4f2bf1e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/192697
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-30 11:56:30 -06:00
|
|
|
var a [10]int // ERROR "moved to heap: a$"
|
2019-04-01 12:58:33 -06:00
|
|
|
b := a[:]
|
|
|
|
foo151(&b[4:8][0])
|
2014-05-12 12:45:05 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func bar151c() {
|
2015-02-19 12:00:11 -07:00
|
|
|
var a [64]int // ERROR "moved to heap: a$"
|
2014-05-12 12:45:05 -06:00
|
|
|
a[4] = 101
|
2019-04-01 12:58:33 -06:00
|
|
|
foo151(&(&a)[4:8:8][0])
|
2014-05-12 12:45:05 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func bar151d() {
|
cmd/compile: silence esc diagnostics about directiface OCONVIFACEs
In general, a conversion to interface type may require values to be
boxed, which in turn necessitates escape analysis to determine whether
the boxed representation can be stack allocated.
However, esc.go used to unconditionally print escape analysis
decisions about OCONVIFACE, even for conversions that don't require
boxing (e.g., pointers, channels, maps, functions).
For test compatibility with esc.go, escape.go similarly printed these
useless diagnostics. This CL removes the diagnostics, and updates test
expectations accordingly.
Change-Id: I97c57a4a08e44d265bba516c78426ff4f2bf1e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/192697
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-30 11:56:30 -06:00
|
|
|
var a [10]int // ERROR "moved to heap: a$"
|
2019-04-01 12:58:33 -06:00
|
|
|
b := a[:]
|
|
|
|
foo151(&b[4:8:8][0])
|
2014-05-12 12:45:05 -06:00
|
|
|
}
|
cmd/gc: fix escape analysis of func returning indirect of parameter
I introduced this bug when I changed the escape
analysis to run in phases based on call graph
dependency order, in order to be more precise about
inputs escaping back to outputs (functions returning
their arguments).
Given
func f(z **int) *int { return *z }
we were tagging the function as 'z does not escape
and is not returned', which is all true, but not
enough information.
If used as:
var x int
p := &x
q := &p
leak(f(q))
then the compiler might try to keep x, p, and q all
on the stack, since (according to the recorded
information) nothing interesting ends up being
passed to leak.
In fact since f returns *q = p, &x is passed to leak
and x needs to be heap allocated.
To trigger the bug, you need a chain that the
compiler wants to keep on the stack (like x, p, q
above), and you need a function that returns an
indirect of its argument, and you need to pass the
head of the chain to that function. This doesn't
come up very often: this bug has been present since
June 2012 (between Go 1 and Go 1.1) and we haven't
seen it until now. It helps that most functions that
return indirects are getters that are simple enough
to be inlined, avoiding the bug.
Earlier versions of Go also had the benefit that if
&x really wasn't used beyond x's lifetime, nothing
broke if you put &x in a heap-allocated structure
accidentally. With the new stack copying, though,
heap-allocated structures containing &x are not
updated when the stack is copied and x moves,
leading to crashes in Go 1.3 that were not crashes
in Go 1.2 or Go 1.1.
The fix is in two parts.
First, in the analysis of a function, recognize when
a value obtained via indirect of a parameter ends up
being returned. Mark those parameters as having
content escape back to the return results (but we
don't bother to write down which result).
Second, when using the analysis to analyze, say,
f(q), mark parameters with content escaping as
having any indirections escape to the heap. (We
don't bother trying to match the content to the
return value.)
The fix could be less precise (simpler).
In the first part we might mark all content-escaping
parameters as plain escaping, and then the second
part could be dropped. Or we might assume that when
calling f(q) all the things pointed at by q escape
always (for any f and q).
The fix could also be more precise (more complex).
We might record the specific mapping from parameter
to result along with the number of indirects from the
parameter to the thing being returned as the result,
and then at the call sites we could set up exactly the
right graph for the called function. That would make
notleaks(f(q)) be able to keep x on the stack, because
the reuslt of f(q) isn't passed to anything that leaks it.
The less precise the fix, the more stack allocations
become heap allocations.
This fix is exactly as precise as it needs to be so that
none of the current stack allocations in the standard
library turn into heap allocations.
Fixes #8120.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews, khr, r
https://golang.org/cl/102040046
2014-06-03 09:35:59 -06:00
|
|
|
|
|
|
|
// issue 8120
|
|
|
|
|
|
|
|
type U struct {
|
|
|
|
s *string
|
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func (u *U) String() *string { // ERROR "leaking param: u to result ~r0 level=1$"
|
cmd/gc: fix escape analysis of func returning indirect of parameter
I introduced this bug when I changed the escape
analysis to run in phases based on call graph
dependency order, in order to be more precise about
inputs escaping back to outputs (functions returning
their arguments).
Given
func f(z **int) *int { return *z }
we were tagging the function as 'z does not escape
and is not returned', which is all true, but not
enough information.
If used as:
var x int
p := &x
q := &p
leak(f(q))
then the compiler might try to keep x, p, and q all
on the stack, since (according to the recorded
information) nothing interesting ends up being
passed to leak.
In fact since f returns *q = p, &x is passed to leak
and x needs to be heap allocated.
To trigger the bug, you need a chain that the
compiler wants to keep on the stack (like x, p, q
above), and you need a function that returns an
indirect of its argument, and you need to pass the
head of the chain to that function. This doesn't
come up very often: this bug has been present since
June 2012 (between Go 1 and Go 1.1) and we haven't
seen it until now. It helps that most functions that
return indirects are getters that are simple enough
to be inlined, avoiding the bug.
Earlier versions of Go also had the benefit that if
&x really wasn't used beyond x's lifetime, nothing
broke if you put &x in a heap-allocated structure
accidentally. With the new stack copying, though,
heap-allocated structures containing &x are not
updated when the stack is copied and x moves,
leading to crashes in Go 1.3 that were not crashes
in Go 1.2 or Go 1.1.
The fix is in two parts.
First, in the analysis of a function, recognize when
a value obtained via indirect of a parameter ends up
being returned. Mark those parameters as having
content escape back to the return results (but we
don't bother to write down which result).
Second, when using the analysis to analyze, say,
f(q), mark parameters with content escaping as
having any indirections escape to the heap. (We
don't bother trying to match the content to the
return value.)
The fix could be less precise (simpler).
In the first part we might mark all content-escaping
parameters as plain escaping, and then the second
part could be dropped. Or we might assume that when
calling f(q) all the things pointed at by q escape
always (for any f and q).
The fix could also be more precise (more complex).
We might record the specific mapping from parameter
to result along with the number of indirects from the
parameter to the thing being returned as the result,
and then at the call sites we could set up exactly the
right graph for the called function. That would make
notleaks(f(q)) be able to keep x on the stack, because
the reuslt of f(q) isn't passed to anything that leaks it.
The less precise the fix, the more stack allocations
become heap allocations.
This fix is exactly as precise as it needs to be so that
none of the current stack allocations in the standard
library turn into heap allocations.
Fixes #8120.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews, khr, r
https://golang.org/cl/102040046
2014-06-03 09:35:59 -06:00
|
|
|
return u.s
|
|
|
|
}
|
|
|
|
|
|
|
|
type V struct {
|
|
|
|
s *string
|
|
|
|
}
|
|
|
|
|
cmd/compile: update escape analysis tests for newescape
The new escape analysis implementation tries to emit debugging
diagnostics that are compatible with the existing implementation, but
there's a handful of cases that are easier to handle by updating the
test expectations instead.
For regress tests that need updating, the original file is copied to
oldescapeXXX.go.go with -newescape=false added to the //errorcheck
line, while the file is updated in place with -newescape=true and new
test requirements.
Notable test changes:
1) escape_because.go looks for a lot of detailed internal debugging
messages that are fairly particular to how esc.go works and that I
haven't attempted to port over to escape.go yet.
2) There are a lot of "leaking param: x to result ~r1 level=-1"
messages for code like
func(p *int) *T { return &T{p} }
that were simply wrong. Here &T must be heap allocated unconditionally
(because it's being returned); and since p is stored into it, p
escapes unconditionally too. esc.go incorrectly reports that p escapes
conditionally only if the returned pointer escaped.
3) esc.go used to print each "leaking param" analysis result as it
discovered them, which could lead to redundant messages (e.g., that a
param leaks at level=0 and level=1). escape.go instead prints
everything at the end, once it knows the shortest path to each sink.
4) esc.go didn't precisely model direct-interface types, resulting in
some values unnecessarily escaping to the heap when stored into
non-escaping interface values.
5) For functions written in assembly, esc.go only printed "does not
escape" messages, whereas escape.go prints "does not escape" or
"leaking param" as appropriate, consistent with the behavior for
functions written in Go.
6) 12 tests included "BAD" annotations identifying cases where esc.go
was unnecessarily heap allocating something. These are all fixed by
escape.go.
Updates #23109.
Change-Id: Iabc9eb14c94c9cadde3b183478d1fd54f013502f
Reviewed-on: https://go-review.googlesource.com/c/go/+/170447
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
2019-04-02 15:44:13 -06:00
|
|
|
func NewV(u U) *V { // ERROR "leaking param: u$"
|
2019-04-01 12:58:33 -06:00
|
|
|
return &V{u.String()} // ERROR "&V literal escapes to heap$"
|
cmd/gc: fix escape analysis of func returning indirect of parameter
I introduced this bug when I changed the escape
analysis to run in phases based on call graph
dependency order, in order to be more precise about
inputs escaping back to outputs (functions returning
their arguments).
Given
func f(z **int) *int { return *z }
we were tagging the function as 'z does not escape
and is not returned', which is all true, but not
enough information.
If used as:
var x int
p := &x
q := &p
leak(f(q))
then the compiler might try to keep x, p, and q all
on the stack, since (according to the recorded
information) nothing interesting ends up being
passed to leak.
In fact since f returns *q = p, &x is passed to leak
and x needs to be heap allocated.
To trigger the bug, you need a chain that the
compiler wants to keep on the stack (like x, p, q
above), and you need a function that returns an
indirect of its argument, and you need to pass the
head of the chain to that function. This doesn't
come up very often: this bug has been present since
June 2012 (between Go 1 and Go 1.1) and we haven't
seen it until now. It helps that most functions that
return indirects are getters that are simple enough
to be inlined, avoiding the bug.
Earlier versions of Go also had the benefit that if
&x really wasn't used beyond x's lifetime, nothing
broke if you put &x in a heap-allocated structure
accidentally. With the new stack copying, though,
heap-allocated structures containing &x are not
updated when the stack is copied and x moves,
leading to crashes in Go 1.3 that were not crashes
in Go 1.2 or Go 1.1.
The fix is in two parts.
First, in the analysis of a function, recognize when
a value obtained via indirect of a parameter ends up
being returned. Mark those parameters as having
content escape back to the return results (but we
don't bother to write down which result).
Second, when using the analysis to analyze, say,
f(q), mark parameters with content escaping as
having any indirections escape to the heap. (We
don't bother trying to match the content to the
return value.)
The fix could be less precise (simpler).
In the first part we might mark all content-escaping
parameters as plain escaping, and then the second
part could be dropped. Or we might assume that when
calling f(q) all the things pointed at by q escape
always (for any f and q).
The fix could also be more precise (more complex).
We might record the specific mapping from parameter
to result along with the number of indirects from the
parameter to the thing being returned as the result,
and then at the call sites we could set up exactly the
right graph for the called function. That would make
notleaks(f(q)) be able to keep x on the stack, because
the reuslt of f(q) isn't passed to anything that leaks it.
The less precise the fix, the more stack allocations
become heap allocations.
This fix is exactly as precise as it needs to be so that
none of the current stack allocations in the standard
library turn into heap allocations.
Fixes #8120.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews, khr, r
https://golang.org/cl/102040046
2014-06-03 09:35:59 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
func foo152() {
|
cmd/compile: silence esc diagnostics about directiface OCONVIFACEs
In general, a conversion to interface type may require values to be
boxed, which in turn necessitates escape analysis to determine whether
the boxed representation can be stack allocated.
However, esc.go used to unconditionally print escape analysis
decisions about OCONVIFACE, even for conversions that don't require
boxing (e.g., pointers, channels, maps, functions).
For test compatibility with esc.go, escape.go similarly printed these
useless diagnostics. This CL removes the diagnostics, and updates test
expectations accordingly.
Change-Id: I97c57a4a08e44d265bba516c78426ff4f2bf1e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/192697
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-30 11:56:30 -06:00
|
|
|
a := "a" // ERROR "moved to heap: a$"
|
2019-04-01 12:58:33 -06:00
|
|
|
u := U{&a}
|
cmd/gc: fix escape analysis of func returning indirect of parameter
I introduced this bug when I changed the escape
analysis to run in phases based on call graph
dependency order, in order to be more precise about
inputs escaping back to outputs (functions returning
their arguments).
Given
func f(z **int) *int { return *z }
we were tagging the function as 'z does not escape
and is not returned', which is all true, but not
enough information.
If used as:
var x int
p := &x
q := &p
leak(f(q))
then the compiler might try to keep x, p, and q all
on the stack, since (according to the recorded
information) nothing interesting ends up being
passed to leak.
In fact since f returns *q = p, &x is passed to leak
and x needs to be heap allocated.
To trigger the bug, you need a chain that the
compiler wants to keep on the stack (like x, p, q
above), and you need a function that returns an
indirect of its argument, and you need to pass the
head of the chain to that function. This doesn't
come up very often: this bug has been present since
June 2012 (between Go 1 and Go 1.1) and we haven't
seen it until now. It helps that most functions that
return indirects are getters that are simple enough
to be inlined, avoiding the bug.
Earlier versions of Go also had the benefit that if
&x really wasn't used beyond x's lifetime, nothing
broke if you put &x in a heap-allocated structure
accidentally. With the new stack copying, though,
heap-allocated structures containing &x are not
updated when the stack is copied and x moves,
leading to crashes in Go 1.3 that were not crashes
in Go 1.2 or Go 1.1.
The fix is in two parts.
First, in the analysis of a function, recognize when
a value obtained via indirect of a parameter ends up
being returned. Mark those parameters as having
content escape back to the return results (but we
don't bother to write down which result).
Second, when using the analysis to analyze, say,
f(q), mark parameters with content escaping as
having any indirections escape to the heap. (We
don't bother trying to match the content to the
return value.)
The fix could be less precise (simpler).
In the first part we might mark all content-escaping
parameters as plain escaping, and then the second
part could be dropped. Or we might assume that when
calling f(q) all the things pointed at by q escape
always (for any f and q).
The fix could also be more precise (more complex).
We might record the specific mapping from parameter
to result along with the number of indirects from the
parameter to the thing being returned as the result,
and then at the call sites we could set up exactly the
right graph for the called function. That would make
notleaks(f(q)) be able to keep x on the stack, because
the reuslt of f(q) isn't passed to anything that leaks it.
The less precise the fix, the more stack allocations
become heap allocations.
This fix is exactly as precise as it needs to be so that
none of the current stack allocations in the standard
library turn into heap allocations.
Fixes #8120.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews, khr, r
https://golang.org/cl/102040046
2014-06-03 09:35:59 -06:00
|
|
|
v := NewV(u)
|
|
|
|
println(v)
|
|
|
|
}
|
2014-06-11 09:48:47 -06:00
|
|
|
|
|
|
|
// issue 8176 - &x in type switch body not marked as escaping
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func foo153(v interface{}) *int { // ERROR "v does not escape"
|
2014-06-11 09:48:47 -06:00
|
|
|
switch x := v.(type) {
|
2015-02-19 12:00:11 -07:00
|
|
|
case int: // ERROR "moved to heap: x$"
|
2019-04-01 12:58:33 -06:00
|
|
|
return &x
|
2014-06-11 09:48:47 -06:00
|
|
|
}
|
|
|
|
panic(0)
|
|
|
|
}
|
2014-06-11 12:21:06 -06:00
|
|
|
|
|
|
|
// issue 8185 - &result escaping into result
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func f() (x int, y *int) { // ERROR "moved to heap: x$"
|
2019-04-01 12:58:33 -06:00
|
|
|
y = &x
|
2014-06-11 12:21:06 -06:00
|
|
|
return
|
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func g() (x interface{}) { // ERROR "moved to heap: x$"
|
cmd/compile: silence esc diagnostics about directiface OCONVIFACEs
In general, a conversion to interface type may require values to be
boxed, which in turn necessitates escape analysis to determine whether
the boxed representation can be stack allocated.
However, esc.go used to unconditionally print escape analysis
decisions about OCONVIFACE, even for conversions that don't require
boxing (e.g., pointers, channels, maps, functions).
For test compatibility with esc.go, escape.go similarly printed these
useless diagnostics. This CL removes the diagnostics, and updates test
expectations accordingly.
Change-Id: I97c57a4a08e44d265bba516c78426ff4f2bf1e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/192697
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-30 11:56:30 -06:00
|
|
|
x = &x
|
2014-06-11 12:21:06 -06:00
|
|
|
return
|
|
|
|
}
|
2015-01-19 13:46:22 -07:00
|
|
|
|
|
|
|
var sink interface{}
|
|
|
|
|
|
|
|
type Lit struct {
|
|
|
|
p *int
|
|
|
|
}
|
|
|
|
|
|
|
|
func ptrlitNoescape() {
|
|
|
|
// Both literal and element do not escape.
|
|
|
|
i := 0
|
2019-09-12 11:18:03 -06:00
|
|
|
x := &Lit{&i} // ERROR "&Lit literal does not escape$"
|
2015-01-19 13:46:22 -07:00
|
|
|
_ = x
|
|
|
|
}
|
|
|
|
|
|
|
|
func ptrlitNoEscape2() {
|
|
|
|
// Literal does not escape, but element does.
|
2015-02-19 12:00:11 -07:00
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
2019-09-12 11:18:03 -06:00
|
|
|
x := &Lit{&i} // ERROR "&Lit literal does not escape$"
|
cmd/compile: silence esc diagnostics about directiface OCONVIFACEs
In general, a conversion to interface type may require values to be
boxed, which in turn necessitates escape analysis to determine whether
the boxed representation can be stack allocated.
However, esc.go used to unconditionally print escape analysis
decisions about OCONVIFACE, even for conversions that don't require
boxing (e.g., pointers, channels, maps, functions).
For test compatibility with esc.go, escape.go similarly printed these
useless diagnostics. This CL removes the diagnostics, and updates test
expectations accordingly.
Change-Id: I97c57a4a08e44d265bba516c78426ff4f2bf1e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/192697
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-30 11:56:30 -06:00
|
|
|
sink = *x
|
2015-01-19 13:46:22 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
func ptrlitEscape() {
|
|
|
|
// Both literal and element escape.
|
2015-02-19 12:00:11 -07:00
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
2019-04-01 12:58:33 -06:00
|
|
|
x := &Lit{&i} // ERROR "&Lit literal escapes to heap$"
|
cmd/compile: silence esc diagnostics about directiface OCONVIFACEs
In general, a conversion to interface type may require values to be
boxed, which in turn necessitates escape analysis to determine whether
the boxed representation can be stack allocated.
However, esc.go used to unconditionally print escape analysis
decisions about OCONVIFACE, even for conversions that don't require
boxing (e.g., pointers, channels, maps, functions).
For test compatibility with esc.go, escape.go similarly printed these
useless diagnostics. This CL removes the diagnostics, and updates test
expectations accordingly.
Change-Id: I97c57a4a08e44d265bba516c78426ff4f2bf1e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/192697
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-30 11:56:30 -06:00
|
|
|
sink = x
|
2015-01-19 13:46:22 -07:00
|
|
|
}
|
2015-01-16 13:30:35 -07:00
|
|
|
|
|
|
|
// self-assignments
|
|
|
|
|
|
|
|
type Buffer struct {
|
2018-09-04 14:14:53 -06:00
|
|
|
arr [64]byte
|
|
|
|
arrPtr *[64]byte
|
|
|
|
buf1 []byte
|
|
|
|
buf2 []byte
|
|
|
|
str1 string
|
|
|
|
str2 string
|
2015-01-16 13:30:35 -07:00
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func (b *Buffer) foo() { // ERROR "b does not escape$"
|
2018-09-19 06:53:03 -06:00
|
|
|
b.buf1 = b.buf1[1:2] // ERROR "\(\*Buffer\).foo ignoring self-assignment in b.buf1 = b.buf1\[1:2\]$"
|
|
|
|
b.buf1 = b.buf1[1:2:3] // ERROR "\(\*Buffer\).foo ignoring self-assignment in b.buf1 = b.buf1\[1:2:3\]$"
|
|
|
|
b.buf1 = b.buf2[1:2] // ERROR "\(\*Buffer\).foo ignoring self-assignment in b.buf1 = b.buf2\[1:2\]$"
|
|
|
|
b.buf1 = b.buf2[1:2:3] // ERROR "\(\*Buffer\).foo ignoring self-assignment in b.buf1 = b.buf2\[1:2:3\]$"
|
2015-01-16 13:30:35 -07:00
|
|
|
}
|
|
|
|
|
2015-02-19 12:00:11 -07:00
|
|
|
func (b *Buffer) bar() { // ERROR "leaking param: b$"
|
2019-04-01 12:58:33 -06:00
|
|
|
b.buf1 = b.arr[1:2]
|
2015-01-16 13:30:35 -07:00
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func (b *Buffer) arrayPtr() { // ERROR "b does not escape"
|
2018-09-19 06:53:03 -06:00
|
|
|
b.buf1 = b.arrPtr[1:2] // ERROR "\(\*Buffer\).arrayPtr ignoring self-assignment in b.buf1 = b.arrPtr\[1:2\]$"
|
|
|
|
b.buf1 = b.arrPtr[1:2:3] // ERROR "\(\*Buffer\).arrayPtr ignoring self-assignment in b.buf1 = b.arrPtr\[1:2:3\]$"
|
2018-09-04 14:14:53 -06:00
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func (b *Buffer) baz() { // ERROR "b does not escape$"
|
2018-09-19 06:53:03 -06:00
|
|
|
b.str1 = b.str1[1:2] // ERROR "\(\*Buffer\).baz ignoring self-assignment in b.str1 = b.str1\[1:2\]$"
|
|
|
|
b.str1 = b.str2[1:2] // ERROR "\(\*Buffer\).baz ignoring self-assignment in b.str1 = b.str2\[1:2\]$"
|
2015-01-16 13:30:35 -07:00
|
|
|
}
|
|
|
|
|
cmd/internal/gc: improve flow of input params to output params
This includes the following information in the per-function summary:
outK = paramJ encoded in outK bits for paramJ
outK = *paramJ encoded in outK bits for paramJ
heap = paramJ EscHeap
heap = *paramJ EscContentEscapes
Note that (currently) if the address of a parameter is taken and
returned, necessarily a heap allocation occurred to contain that
reference, and the heap can never refer to stack, therefore the
parameter and everything downstream from it escapes to the heap.
The per-function summary information now has a tuneable number of bits
(2 is probably noticeably better than 1, 3 is likely overkill, but it
is now easy to check and the -m debugging output includes information
that allows you to figure out if more would be better.)
A new test was added to check pointer flow through struct-typed and
*struct-typed parameters and returns; some of these are sensitive to
the number of summary bits, and ought to yield better results with a
more competent escape analysis algorithm. Another new test checks
(some) correctness with array parameters, results, and operations.
The old analysis inferred a piece of plan9 runtime was non-escaping by
counteracting overconservative analysis with buggy analysis; with the
bug fixed, the result was too conservative (and it's not easy to fix
in this framework) so the source code was tweaked to get the desired
result. A test was added against the discovered bug.
The escape analysis was further improved splitting the "level" into
3 parts, one tracking the conventional "level" and the other two
computing the highest-level-suffix-from-copy, which is used to
generally model the cancelling effect of indirection applied to
address-of.
With the improved escape analysis enabled, it was necessary to
modify one of the runtime tests because it now attempts to allocate
too much on the (small, fixed-size) G0 (system) stack and this
failed the test.
Compiling src/std after touching src/runtime/*.go with -m logging
turned on shows 420 fewer heap allocation sites (10538 vs 10968).
Profiling allocations in src/html/template with
for i in {1..5} ;
do go tool 6g -memprofile=mastx.${i}.prof -memprofilerate=1 *.go;
go tool pprof -alloc_objects -text mastx.${i}.prof ;
done
showed a 15% reduction in allocations performed by the compiler.
Update #3753
Update #4720
Fixes #10466
Change-Id: I0fd97d5f5ac527b45f49e2218d158a6e89951432
Reviewed-on: https://go-review.googlesource.com/8202
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2015-03-26 14:36:15 -06:00
|
|
|
func (b *Buffer) bat() { // ERROR "leaking param content: b$"
|
2015-02-19 12:00:11 -07:00
|
|
|
o := new(Buffer) // ERROR "new\(Buffer\) escapes to heap$"
|
2015-01-16 13:30:35 -07:00
|
|
|
o.buf1 = b.buf1[1:2]
|
cmd/compile: silence esc diagnostics about directiface OCONVIFACEs
In general, a conversion to interface type may require values to be
boxed, which in turn necessitates escape analysis to determine whether
the boxed representation can be stack allocated.
However, esc.go used to unconditionally print escape analysis
decisions about OCONVIFACE, even for conversions that don't require
boxing (e.g., pointers, channels, maps, functions).
For test compatibility with esc.go, escape.go similarly printed these
useless diagnostics. This CL removes the diagnostics, and updates test
expectations accordingly.
Change-Id: I97c57a4a08e44d265bba516c78426ff4f2bf1e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/192697
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-30 11:56:30 -06:00
|
|
|
sink = o
|
2015-01-16 13:30:35 -07:00
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func quux(sp *string, bp *[]byte) { // ERROR "bp does not escape$" "sp does not escape$"
|
2018-09-19 06:53:03 -06:00
|
|
|
*sp = (*sp)[1:2] // ERROR "quux ignoring self-assignment in \*sp = \(\*sp\)\[1:2\]$"
|
|
|
|
*bp = (*bp)[1:2] // ERROR "quux ignoring self-assignment in \*bp = \(\*bp\)\[1:2\]$"
|
2015-01-16 13:30:35 -07:00
|
|
|
}
|
2015-01-21 07:37:59 -07:00
|
|
|
|
|
|
|
type StructWithString struct {
|
|
|
|
p *int
|
|
|
|
s string
|
|
|
|
}
|
|
|
|
|
|
|
|
// This is escape analysis false negative.
|
|
|
|
// We assign the pointer to x.p but leak x.s. Escape analysis coarsens flows
|
|
|
|
// to just x, and thus &i looks escaping.
|
|
|
|
func fieldFlowTracking() {
|
|
|
|
var x StructWithString
|
cmd/compile: silence esc diagnostics about directiface OCONVIFACEs
In general, a conversion to interface type may require values to be
boxed, which in turn necessitates escape analysis to determine whether
the boxed representation can be stack allocated.
However, esc.go used to unconditionally print escape analysis
decisions about OCONVIFACE, even for conversions that don't require
boxing (e.g., pointers, channels, maps, functions).
For test compatibility with esc.go, escape.go similarly printed these
useless diagnostics. This CL removes the diagnostics, and updates test
expectations accordingly.
Change-Id: I97c57a4a08e44d265bba516c78426ff4f2bf1e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/192697
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-30 11:56:30 -06:00
|
|
|
i := 0 // ERROR "moved to heap: i$"
|
2019-04-01 12:58:33 -06:00
|
|
|
x.p = &i
|
2015-02-19 12:00:11 -07:00
|
|
|
sink = x.s // ERROR "x.s escapes to heap$"
|
2015-01-21 07:37:59 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
// String operations.
|
|
|
|
|
|
|
|
func slicebytetostring0() {
|
2019-09-12 11:18:03 -06:00
|
|
|
b := make([]byte, 20) // ERROR "make\(\[\]byte, 20\) does not escape$"
|
|
|
|
s := string(b) // ERROR "string\(b\) does not escape$"
|
2015-01-21 07:37:59 -07:00
|
|
|
_ = s
|
|
|
|
}
|
|
|
|
|
|
|
|
func slicebytetostring1() {
|
2019-09-12 11:18:03 -06:00
|
|
|
b := make([]byte, 20) // ERROR "make\(\[\]byte, 20\) does not escape$"
|
|
|
|
s := string(b) // ERROR "string\(b\) does not escape$"
|
2015-01-21 07:37:59 -07:00
|
|
|
s1 := s[0:1]
|
|
|
|
_ = s1
|
|
|
|
}
|
|
|
|
|
|
|
|
func slicebytetostring2() {
|
2019-09-12 11:18:03 -06:00
|
|
|
b := make([]byte, 20) // ERROR "make\(\[\]byte, 20\) does not escape$"
|
2015-02-19 12:00:11 -07:00
|
|
|
s := string(b) // ERROR "string\(b\) escapes to heap$"
|
|
|
|
s1 := s[0:1] // ERROR "moved to heap: s1$"
|
cmd/compile: silence esc diagnostics about directiface OCONVIFACEs
In general, a conversion to interface type may require values to be
boxed, which in turn necessitates escape analysis to determine whether
the boxed representation can be stack allocated.
However, esc.go used to unconditionally print escape analysis
decisions about OCONVIFACE, even for conversions that don't require
boxing (e.g., pointers, channels, maps, functions).
For test compatibility with esc.go, escape.go similarly printed these
useless diagnostics. This CL removes the diagnostics, and updates test
expectations accordingly.
Change-Id: I97c57a4a08e44d265bba516c78426ff4f2bf1e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/192697
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-30 11:56:30 -06:00
|
|
|
sink = &s1
|
2015-01-21 07:37:59 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
func slicebytetostring3() {
|
2019-09-12 11:18:03 -06:00
|
|
|
b := make([]byte, 20) // ERROR "make\(\[\]byte, 20\) does not escape$"
|
2015-02-19 12:00:11 -07:00
|
|
|
s := string(b) // ERROR "string\(b\) escapes to heap$"
|
2015-01-21 07:37:59 -07:00
|
|
|
s1 := s[0:1]
|
2015-02-19 12:00:11 -07:00
|
|
|
sink = s1 // ERROR "s1 escapes to heap$"
|
2015-01-21 07:37:59 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
func addstr0() {
|
|
|
|
s0 := "a"
|
|
|
|
s1 := "b"
|
2019-09-12 11:18:03 -06:00
|
|
|
s := s0 + s1 // ERROR "s0 \+ s1 does not escape$"
|
2015-01-21 07:37:59 -07:00
|
|
|
_ = s
|
|
|
|
}
|
|
|
|
|
|
|
|
func addstr1() {
|
|
|
|
s0 := "a"
|
|
|
|
s1 := "b"
|
|
|
|
s := "c"
|
2019-09-12 11:18:03 -06:00
|
|
|
s += s0 + s1 // ERROR "s0 \+ s1 does not escape$"
|
2015-01-21 07:37:59 -07:00
|
|
|
_ = s
|
|
|
|
}
|
|
|
|
|
|
|
|
func addstr2() {
|
2019-09-12 11:18:03 -06:00
|
|
|
b := make([]byte, 20) // ERROR "make\(\[\]byte, 20\) does not escape$"
|
2015-01-21 07:37:59 -07:00
|
|
|
s0 := "a"
|
2019-09-12 11:18:03 -06:00
|
|
|
s := string(b) + s0 // ERROR "string\(b\) \+ s0 does not escape$" "string\(b\) does not escape$"
|
2015-01-21 07:37:59 -07:00
|
|
|
_ = s
|
|
|
|
}
|
|
|
|
|
|
|
|
func addstr3() {
|
|
|
|
s0 := "a"
|
|
|
|
s1 := "b"
|
2015-02-19 12:00:11 -07:00
|
|
|
s := s0 + s1 // ERROR "s0 \+ s1 escapes to heap$"
|
2015-01-21 07:37:59 -07:00
|
|
|
s2 := s[0:1]
|
2015-02-19 12:00:11 -07:00
|
|
|
sink = s2 // ERROR "s2 escapes to heap$"
|
2015-01-21 07:37:59 -07:00
|
|
|
}
|
2015-01-27 22:42:20 -07:00
|
|
|
|
|
|
|
func intstring0() bool {
|
|
|
|
// string does not escape
|
|
|
|
x := '0'
|
2019-09-12 11:18:03 -06:00
|
|
|
s := string(x) // ERROR "string\(x\) does not escape$"
|
2015-01-27 22:42:20 -07:00
|
|
|
return s == "0"
|
|
|
|
}
|
|
|
|
|
|
|
|
func intstring1() string {
|
|
|
|
// string does not escape, but the buffer does
|
|
|
|
x := '0'
|
2015-02-19 12:00:11 -07:00
|
|
|
s := string(x) // ERROR "string\(x\) escapes to heap$"
|
2015-01-27 22:42:20 -07:00
|
|
|
return s
|
|
|
|
}
|
|
|
|
|
|
|
|
func intstring2() {
|
|
|
|
// string escapes to heap
|
|
|
|
x := '0'
|
2015-02-19 12:00:11 -07:00
|
|
|
s := string(x) // ERROR "moved to heap: s$" "string\(x\) escapes to heap$"
|
cmd/compile: silence esc diagnostics about directiface OCONVIFACEs
In general, a conversion to interface type may require values to be
boxed, which in turn necessitates escape analysis to determine whether
the boxed representation can be stack allocated.
However, esc.go used to unconditionally print escape analysis
decisions about OCONVIFACE, even for conversions that don't require
boxing (e.g., pointers, channels, maps, functions).
For test compatibility with esc.go, escape.go similarly printed these
useless diagnostics. This CL removes the diagnostics, and updates test
expectations accordingly.
Change-Id: I97c57a4a08e44d265bba516c78426ff4f2bf1e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/192697
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-30 11:56:30 -06:00
|
|
|
sink = &s
|
2015-01-27 22:42:20 -07:00
|
|
|
}
|
2015-01-29 23:14:13 -07:00
|
|
|
|
|
|
|
func stringtoslicebyte0() {
|
|
|
|
s := "foo"
|
2019-09-12 11:18:03 -06:00
|
|
|
x := []byte(s) // ERROR "\(\[\]byte\)\(s\) does not escape$"
|
2015-01-29 23:14:13 -07:00
|
|
|
_ = x
|
|
|
|
}
|
|
|
|
|
|
|
|
func stringtoslicebyte1() []byte {
|
|
|
|
s := "foo"
|
2015-02-19 12:00:11 -07:00
|
|
|
return []byte(s) // ERROR "\(\[\]byte\)\(s\) escapes to heap$"
|
2015-01-29 23:14:13 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
func stringtoslicebyte2() {
|
|
|
|
s := "foo"
|
2015-02-19 12:00:11 -07:00
|
|
|
sink = []byte(s) // ERROR "\(\[\]byte\)\(s\) escapes to heap$"
|
2015-01-29 23:14:13 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
func stringtoslicerune0() {
|
|
|
|
s := "foo"
|
2019-09-12 11:18:03 -06:00
|
|
|
x := []rune(s) // ERROR "\(\[\]rune\)\(s\) does not escape$"
|
2015-01-29 23:14:13 -07:00
|
|
|
_ = x
|
|
|
|
}
|
|
|
|
|
|
|
|
func stringtoslicerune1() []rune {
|
|
|
|
s := "foo"
|
2015-02-19 12:00:11 -07:00
|
|
|
return []rune(s) // ERROR "\(\[\]rune\)\(s\) escapes to heap$"
|
2015-01-29 23:14:13 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
func stringtoslicerune2() {
|
|
|
|
s := "foo"
|
2015-02-19 12:00:11 -07:00
|
|
|
sink = []rune(s) // ERROR "\(\[\]rune\)\(s\) escapes to heap$"
|
2015-01-29 23:14:13 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
func slicerunetostring0() {
|
2019-09-12 11:18:03 -06:00
|
|
|
r := []rune{1, 2, 3} // ERROR "\[\]rune literal does not escape$"
|
|
|
|
s := string(r) // ERROR "string\(r\) does not escape$"
|
2015-01-29 23:14:13 -07:00
|
|
|
_ = s
|
|
|
|
}
|
|
|
|
|
|
|
|
func slicerunetostring1() string {
|
2019-09-12 11:18:03 -06:00
|
|
|
r := []rune{1, 2, 3} // ERROR "\[\]rune literal does not escape$"
|
2015-02-19 12:00:11 -07:00
|
|
|
return string(r) // ERROR "string\(r\) escapes to heap$"
|
2015-01-29 23:14:13 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
func slicerunetostring2() {
|
2019-09-12 11:18:03 -06:00
|
|
|
r := []rune{1, 2, 3} // ERROR "\[\]rune literal does not escape$"
|
2015-02-19 12:00:11 -07:00
|
|
|
sink = string(r) // ERROR "string\(r\) escapes to heap$"
|
2015-01-29 23:14:13 -07:00
|
|
|
}
|
2015-01-29 09:40:02 -07:00
|
|
|
|
|
|
|
func makemap0() {
|
2019-09-12 11:18:03 -06:00
|
|
|
m := make(map[int]int) // ERROR "make\(map\[int\]int\) does not escape$"
|
2015-01-29 09:40:02 -07:00
|
|
|
m[0] = 0
|
|
|
|
m[1]++
|
|
|
|
delete(m, 1)
|
2015-02-19 12:00:11 -07:00
|
|
|
sink = m[0] // ERROR "m\[0\] escapes to heap$"
|
2015-01-29 09:40:02 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
func makemap1() map[int]int {
|
2015-02-19 12:00:11 -07:00
|
|
|
return make(map[int]int) // ERROR "make\(map\[int\]int\) escapes to heap$"
|
2015-01-29 09:40:02 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
func makemap2() {
|
2015-02-19 12:00:11 -07:00
|
|
|
m := make(map[int]int) // ERROR "make\(map\[int\]int\) escapes to heap$"
|
cmd/compile: silence esc diagnostics about directiface OCONVIFACEs
In general, a conversion to interface type may require values to be
boxed, which in turn necessitates escape analysis to determine whether
the boxed representation can be stack allocated.
However, esc.go used to unconditionally print escape analysis
decisions about OCONVIFACE, even for conversions that don't require
boxing (e.g., pointers, channels, maps, functions).
For test compatibility with esc.go, escape.go similarly printed these
useless diagnostics. This CL removes the diagnostics, and updates test
expectations accordingly.
Change-Id: I97c57a4a08e44d265bba516c78426ff4f2bf1e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/192697
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-08-30 11:56:30 -06:00
|
|
|
sink = m
|
2015-02-19 06:27:32 -07:00
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func nonescapingEface(m map[interface{}]bool) bool { // ERROR "m does not escape$"
|
|
|
|
return m["foo"] // ERROR ".foo. does not escape$"
|
2015-02-19 06:27:32 -07:00
|
|
|
}
|
|
|
|
|
2019-09-12 11:18:03 -06:00
|
|
|
func nonescapingIface(m map[M]bool) bool { // ERROR "m does not escape$"
|
|
|
|
return m[MV(0)] // ERROR "MV\(0\) does not escape$"
|
2015-01-29 09:40:02 -07:00
|
|
|
}
|
2015-04-06 09:17:20 -06:00
|
|
|
|
|
|
|
func issue10353() {
|
2015-02-19 12:00:11 -07:00
|
|
|
x := new(int) // ERROR "new\(int\) escapes to heap$"
|
2015-04-06 09:17:20 -06:00
|
|
|
issue10353a(x)()
|
|
|
|
}
|
|
|
|
|
cmd/compile: update escape analysis tests for newescape
The new escape analysis implementation tries to emit debugging
diagnostics that are compatible with the existing implementation, but
there's a handful of cases that are easier to handle by updating the
test expectations instead.
For regress tests that need updating, the original file is copied to
oldescapeXXX.go.go with -newescape=false added to the //errorcheck
line, while the file is updated in place with -newescape=true and new
test requirements.
Notable test changes:
1) escape_because.go looks for a lot of detailed internal debugging
messages that are fairly particular to how esc.go works and that I
haven't attempted to port over to escape.go yet.
2) There are a lot of "leaking param: x to result ~r1 level=-1"
messages for code like
func(p *int) *T { return &T{p} }
that were simply wrong. Here &T must be heap allocated unconditionally
(because it's being returned); and since p is stored into it, p
escapes unconditionally too. esc.go incorrectly reports that p escapes
conditionally only if the returned pointer escaped.
3) esc.go used to print each "leaking param" analysis result as it
discovered them, which could lead to redundant messages (e.g., that a
param leaks at level=0 and level=1). escape.go instead prints
everything at the end, once it knows the shortest path to each sink.
4) esc.go didn't precisely model direct-interface types, resulting in
some values unnecessarily escaping to the heap when stored into
non-escaping interface values.
5) For functions written in assembly, esc.go only printed "does not
escape" messages, whereas escape.go prints "does not escape" or
"leaking param" as appropriate, consistent with the behavior for
functions written in Go.
6) 12 tests included "BAD" annotations identifying cases where esc.go
was unnecessarily heap allocating something. These are all fixed by
escape.go.
Updates #23109.
Change-Id: Iabc9eb14c94c9cadde3b183478d1fd54f013502f
Reviewed-on: https://go-review.googlesource.com/c/go/+/170447
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
2019-04-02 15:44:13 -06:00
|
|
|
func issue10353a(x *int) func() { // ERROR "leaking param: x$"
|
2015-02-19 12:00:11 -07:00
|
|
|
return func() { // ERROR "func literal escapes to heap$"
|
2015-04-06 09:17:20 -06:00
|
|
|
println(*x)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func issue10353b() {
|
|
|
|
var f func()
|
|
|
|
for {
|
2015-02-19 12:00:11 -07:00
|
|
|
x := new(int) // ERROR "new\(int\) escapes to heap$"
|
|
|
|
f = func() { // ERROR "func literal escapes to heap$"
|
2015-04-06 09:17:20 -06:00
|
|
|
println(*x)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
_ = f
|
|
|
|
}
|
2015-06-24 15:31:57 -06:00
|
|
|
|
|
|
|
func issue11387(x int) func() int {
|
|
|
|
f := func() int { return x } // ERROR "func literal escapes to heap"
|
|
|
|
slice1 := []func() int{f} // ERROR "\[\].* does not escape"
|
|
|
|
slice2 := make([]func() int, 1) // ERROR "make\(.*\) does not escape"
|
|
|
|
copy(slice2, slice1)
|
|
|
|
return slice2[0]
|
|
|
|
}
|
2017-02-27 12:37:54 -07:00
|
|
|
|
|
|
|
func issue12397(x, y int) { // ERROR "moved to heap: y$"
|
|
|
|
// x does not escape below, because all relevant code is dead.
|
|
|
|
if false {
|
|
|
|
gxx = &x
|
|
|
|
} else {
|
2019-04-01 12:58:33 -06:00
|
|
|
gxx = &y
|
2017-02-27 12:37:54 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
if true {
|
2019-04-01 12:58:33 -06:00
|
|
|
gxx = &y
|
2017-02-27 12:37:54 -07:00
|
|
|
} else {
|
|
|
|
gxx = &x
|
|
|
|
}
|
|
|
|
}
|