2015-02-13 14:40:36 -05:00
|
|
|
// Copyright 2011 The Go Authors. All rights reserved.
|
|
|
|
|
// Use of this source code is governed by a BSD-style
|
|
|
|
|
// license that can be found in the LICENSE file.
|
|
|
|
|
|
|
|
|
|
package gc
|
|
|
|
|
|
|
|
|
|
import (
|
|
|
|
|
"fmt"
|
2015-10-20 10:52:41 -07:00
|
|
|
"strconv"
|
2015-02-13 14:40:36 -05:00
|
|
|
"strings"
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
// Run analysis on minimal sets of mutually recursive functions
|
|
|
|
|
// or single non-recursive functions, bottom up.
|
|
|
|
|
//
|
|
|
|
|
// Finding these sets is finding strongly connected components
|
2016-10-12 11:34:47 +09:00
|
|
|
// by reverse topological order in the static call graph.
|
|
|
|
|
// The algorithm (known as Tarjan's algorithm) for doing that is taken from
|
|
|
|
|
// Sedgewick, Algorithms, Second Edition, p. 482, with two adaptations.
|
2015-02-13 14:40:36 -05:00
|
|
|
//
|
2017-02-27 19:56:38 +02:00
|
|
|
// First, a hidden closure function (n.Func.IsHiddenClosure()) cannot be the
|
2015-02-13 14:40:36 -05:00
|
|
|
// root of a connected component. Refusing to use it as a root
|
|
|
|
|
// forces it into the component of the function in which it appears.
|
2015-02-24 12:14:29 -05:00
|
|
|
// This is more convenient for escape analysis.
|
2015-02-13 14:40:36 -05:00
|
|
|
//
|
|
|
|
|
// Second, each function becomes two virtual nodes in the graph,
|
|
|
|
|
// with numbers n and n+1. We record the function's node number as n
|
|
|
|
|
// but search from node n+1. If the search tells us that the component
|
|
|
|
|
// number (min) is n+1, we know that this is a trivial component: one function
|
|
|
|
|
// plus its closures. If the search tells us that the component number is
|
|
|
|
|
// n, then there was a path from node n+1 back to node n, meaning that
|
|
|
|
|
// the function set is mutually recursive. The escape analysis can be
|
|
|
|
|
// more precise when analyzing a single non-recursive function than
|
|
|
|
|
// when analyzing a set of mutually recursive functions.
|
|
|
|
|
|
2015-02-24 12:14:29 -05:00
|
|
|
type bottomUpVisitor struct {
|
2015-09-05 12:30:13 +10:00
|
|
|
analyze func([]*Node, bool)
|
2015-02-24 12:14:29 -05:00
|
|
|
visitgen uint32
|
2015-05-27 00:44:05 -04:00
|
|
|
nodeID map[*Node]uint32
|
2015-09-05 12:30:13 +10:00
|
|
|
stack []*Node
|
2015-02-24 12:14:29 -05:00
|
|
|
}
|
2015-02-13 14:40:36 -05:00
|
|
|
|
2015-02-24 12:14:29 -05:00
|
|
|
// visitBottomUp invokes analyze on the ODCLFUNC nodes listed in list.
|
|
|
|
|
// It calls analyze with successive groups of functions, working from
|
|
|
|
|
// the bottom of the call graph upward. Each time analyze is called with
|
|
|
|
|
// a list of functions, every function on that list only calls other functions
|
|
|
|
|
// on the list or functions that have been passed in previous invocations of
|
|
|
|
|
// analyze. Closures appear in the same list as their outer functions.
|
|
|
|
|
// The lists are as short as possible while preserving those requirements.
|
|
|
|
|
// (In a typical program, many invocations of analyze will be passed just
|
|
|
|
|
// a single function.) The boolean argument 'recursive' passed to analyze
|
|
|
|
|
// specifies whether the functions on the list are mutually recursive.
|
|
|
|
|
// If recursive is false, the list consists of only a single function and its closures.
|
|
|
|
|
// If recursive is true, the list may still contain only a single function,
|
|
|
|
|
// if that function is itself recursive.
|
2016-03-09 20:29:21 -08:00
|
|
|
func visitBottomUp(list []*Node, analyze func(list []*Node, recursive bool)) {
|
2015-02-24 12:14:29 -05:00
|
|
|
var v bottomUpVisitor
|
|
|
|
|
v.analyze = analyze
|
2015-05-27 00:44:05 -04:00
|
|
|
v.nodeID = make(map[*Node]uint32)
|
2016-03-09 20:29:21 -08:00
|
|
|
for _, n := range list {
|
2017-02-27 19:56:38 +02:00
|
|
|
if n.Op == ODCLFUNC && !n.Func.IsHiddenClosure() {
|
2016-03-09 20:29:21 -08:00
|
|
|
v.visit(n)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2015-02-24 12:14:29 -05:00
|
|
|
func (v *bottomUpVisitor) visit(n *Node) uint32 {
|
2015-05-27 00:44:05 -04:00
|
|
|
if id := v.nodeID[n]; id > 0 {
|
2015-02-13 14:40:36 -05:00
|
|
|
// already visited
|
2015-05-27 00:44:05 -04:00
|
|
|
return id
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
2015-02-24 12:14:29 -05:00
|
|
|
v.visitgen++
|
2015-05-27 00:44:05 -04:00
|
|
|
id := v.visitgen
|
|
|
|
|
v.nodeID[n] = id
|
2015-02-24 12:14:29 -05:00
|
|
|
v.visitgen++
|
|
|
|
|
min := v.visitgen
|
2015-02-13 14:40:36 -05:00
|
|
|
|
2015-09-05 12:30:13 +10:00
|
|
|
v.stack = append(v.stack, n)
|
2016-03-03 17:38:14 -08:00
|
|
|
min = v.visitcodelist(n.Nbody, min)
|
2017-02-27 19:56:38 +02:00
|
|
|
if (min == id || min == id+1) && !n.Func.IsHiddenClosure() {
|
2015-02-13 14:40:36 -05:00
|
|
|
// This node is the root of a strongly connected component.
|
|
|
|
|
|
2016-10-12 11:34:47 +09:00
|
|
|
// The original min passed to visitcodelist was v.nodeID[n]+1.
|
|
|
|
|
// If visitcodelist found its way back to v.nodeID[n], then this
|
2015-02-13 14:40:36 -05:00
|
|
|
// block is a set of mutually recursive functions.
|
|
|
|
|
// Otherwise it's just a lone function that does not recurse.
|
2015-05-27 00:44:05 -04:00
|
|
|
recursive := min == id
|
2015-02-13 14:40:36 -05:00
|
|
|
|
|
|
|
|
// Remove connected component from stack.
|
|
|
|
|
// Mark walkgen so that future visits return a large number
|
|
|
|
|
// so as not to affect the caller's min.
|
|
|
|
|
|
2015-09-05 12:30:13 +10:00
|
|
|
var i int
|
|
|
|
|
for i = len(v.stack) - 1; i >= 0; i-- {
|
|
|
|
|
x := v.stack[i]
|
|
|
|
|
if x == n {
|
|
|
|
|
break
|
|
|
|
|
}
|
|
|
|
|
v.nodeID[x] = ^uint32(0)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
2015-05-27 00:44:05 -04:00
|
|
|
v.nodeID[n] = ^uint32(0)
|
2015-09-05 12:30:13 +10:00
|
|
|
block := v.stack[i:]
|
2015-02-13 14:40:36 -05:00
|
|
|
// Run escape analysis on this set of functions.
|
2015-09-05 12:30:13 +10:00
|
|
|
v.stack = v.stack[:i]
|
2015-02-24 12:14:29 -05:00
|
|
|
v.analyze(block, recursive)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return min
|
|
|
|
|
}
|
|
|
|
|
|
2016-03-08 10:26:20 -08:00
|
|
|
func (v *bottomUpVisitor) visitcodelist(l Nodes, min uint32) uint32 {
|
2016-03-08 15:10:26 -08:00
|
|
|
for _, n := range l.Slice() {
|
|
|
|
|
min = v.visitcode(n, min)
|
2016-02-27 14:31:33 -08:00
|
|
|
}
|
|
|
|
|
return min
|
|
|
|
|
}
|
|
|
|
|
|
2015-02-24 12:14:29 -05:00
|
|
|
func (v *bottomUpVisitor) visitcode(n *Node, min uint32) uint32 {
|
2015-02-13 14:40:36 -05:00
|
|
|
if n == nil {
|
|
|
|
|
return min
|
|
|
|
|
}
|
|
|
|
|
|
2015-02-24 12:14:29 -05:00
|
|
|
min = v.visitcodelist(n.Ninit, min)
|
|
|
|
|
min = v.visitcode(n.Left, min)
|
|
|
|
|
min = v.visitcode(n.Right, min)
|
|
|
|
|
min = v.visitcodelist(n.List, min)
|
2016-03-03 17:38:14 -08:00
|
|
|
min = v.visitcodelist(n.Nbody, min)
|
2015-02-24 12:14:29 -05:00
|
|
|
min = v.visitcodelist(n.Rlist, min)
|
2015-02-13 14:40:36 -05:00
|
|
|
|
|
|
|
|
if n.Op == OCALLFUNC || n.Op == OCALLMETH {
|
2015-02-23 16:07:24 -05:00
|
|
|
fn := n.Left
|
2015-02-13 14:40:36 -05:00
|
|
|
if n.Op == OCALLMETH {
|
cmd/compile: change ODOT and friends to use Sym, not Right
The Node type ODOT and its variants all represent a selector, with a
simple name to the right of the dot. Before this change this was
represented by using an ONAME Node in the Right field. This ONAME node
served no useful purpose. This CL changes these Node types to store the
symbol in the Sym field instead, thus not requiring allocating a Node
for each selector.
When compiling x/tools/go/types this CL eliminates nearly 5000 calls to
newname and reduces the total number of Nodes allocated by about 6.6%.
It seems to cut compilation time by 1 to 2 percent.
Getting this right was somewhat subtle, and I added two dubious changes
to produce the exact same output as before. One is to ishairy in
inl.go: the ONAME node increased the cost of ODOT and friends by 1, and
I retained that, although really ODOT is not more expensive than any
other node. The other is to varexpr in walk.go: because the ONAME in
the Right field of an ODOT has no class, varexpr would always return
false for an ODOT, although in fact for some ODOT's it seemingly ought
to return true; I added an && false for now. I will send separate CLs,
that will break toolstash -cmp, to clean these up.
This CL passes toolstash -cmp.
Change-Id: I4af8a10cc59078c436130ce472f25abc3a9b2f80
Reviewed-on: https://go-review.googlesource.com/20890
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2016-03-18 16:52:30 -07:00
|
|
|
fn = n.Left.Sym.Def
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
2015-05-26 22:19:27 -04:00
|
|
|
if fn != nil && fn.Op == ONAME && fn.Class == PFUNC && fn.Name.Defn != nil {
|
|
|
|
|
m := v.visit(fn.Name.Defn)
|
2015-02-13 14:40:36 -05:00
|
|
|
if m < min {
|
|
|
|
|
min = m
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if n.Op == OCLOSURE {
|
2015-05-27 00:44:05 -04:00
|
|
|
m := v.visit(n.Func.Closure)
|
2015-02-13 14:40:36 -05:00
|
|
|
if m < min {
|
|
|
|
|
min = m
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return min
|
|
|
|
|
}
|
|
|
|
|
|
2015-02-24 12:14:29 -05:00
|
|
|
// Escape analysis.
|
|
|
|
|
|
2015-02-13 14:40:36 -05:00
|
|
|
// An escape analysis pass for a set of functions.
|
2015-02-24 12:14:29 -05:00
|
|
|
// The analysis assumes that closures and the functions in which they
|
|
|
|
|
// appear are analyzed together, so that the aliasing between their
|
|
|
|
|
// variables can be modeled more precisely.
|
2015-02-13 14:40:36 -05:00
|
|
|
//
|
|
|
|
|
// First escfunc, esc and escassign recurse over the ast of each
|
|
|
|
|
// function to dig out flow(dst,src) edges between any
|
2016-10-12 11:34:47 +09:00
|
|
|
// pointer-containing nodes and store them in e.nodeEscState(dst).Flowsrc. For
|
2015-02-13 14:40:36 -05:00
|
|
|
// variables assigned to a variable in an outer scope or used as a
|
|
|
|
|
// return value, they store a flow(theSink, src) edge to a fake node
|
|
|
|
|
// 'the Sink'. For variables referenced in closures, an edge
|
|
|
|
|
// flow(closure, &var) is recorded and the flow of a closure itself to
|
|
|
|
|
// an outer scope is tracked the same way as other variables.
|
|
|
|
|
//
|
|
|
|
|
// Then escflood walks the graph starting at theSink and tags all
|
|
|
|
|
// variables of it can reach an & node as escaping and all function
|
|
|
|
|
// parameters it can reach as leaking.
|
|
|
|
|
//
|
|
|
|
|
// If a value's address is taken but the address does not escape,
|
2016-03-01 23:21:55 +00:00
|
|
|
// then the value can stay on the stack. If the value new(T) does
|
2015-02-13 14:40:36 -05:00
|
|
|
// not escape, then new(T) can be rewritten into a stack allocation.
|
|
|
|
|
// The same is true of slice literals.
|
|
|
|
|
//
|
|
|
|
|
// If optimizations are disabled (-N), this code is not used.
|
|
|
|
|
// Instead, the compiler assumes that any value whose address
|
|
|
|
|
// is taken without being immediately dereferenced
|
|
|
|
|
// needs to be moved to the heap, and new(T) and slice
|
|
|
|
|
// literals are always real allocations.
|
|
|
|
|
|
2016-03-09 20:29:21 -08:00
|
|
|
func escapes(all []*Node) {
|
2015-02-24 12:14:29 -05:00
|
|
|
visitBottomUp(all, escAnalyze)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const (
|
|
|
|
|
EscFuncUnknown = 0 + iota
|
|
|
|
|
EscFuncPlanned
|
|
|
|
|
EscFuncStarted
|
|
|
|
|
EscFuncTagged
|
|
|
|
|
)
|
|
|
|
|
|
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 16:36:15 -04:00
|
|
|
// There appear to be some loops in the escape graph, causing
|
|
|
|
|
// arbitrary recursion into deeper and deeper levels.
|
|
|
|
|
// Cut this off safely by making minLevel sticky: once you
|
|
|
|
|
// get that deep, you cannot go down any further but you also
|
|
|
|
|
// cannot go up any further. This is a conservative fix.
|
|
|
|
|
// Making minLevel smaller (more negative) would handle more
|
|
|
|
|
// complex chains of indirections followed by address-of operations,
|
|
|
|
|
// at the cost of repeating the traversal once for each additional
|
|
|
|
|
// allowed level when a loop is encountered. Using -2 suffices to
|
|
|
|
|
// pass all the tests we have written so far, which we assume matches
|
|
|
|
|
// the level of complexity we want the escape analysis code to handle.
|
|
|
|
|
const (
|
|
|
|
|
MinLevel = -2
|
|
|
|
|
)
|
2015-03-05 13:57:36 -05: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 16:36:15 -04:00
|
|
|
// A Level encodes the reference state and context applied to
|
|
|
|
|
// (stack, heap) allocated memory.
|
|
|
|
|
//
|
|
|
|
|
// value is the overall sum of *(1) and &(-1) operations encountered
|
|
|
|
|
// along a path from a destination (sink, return value) to a source
|
|
|
|
|
// (allocation, parameter).
|
|
|
|
|
//
|
|
|
|
|
// suffixValue is the maximum-copy-started-suffix-level applied to a sink.
|
|
|
|
|
// For example:
|
|
|
|
|
// sink = x.left.left --> level=2, x is dereferenced twice and does not escape to sink.
|
|
|
|
|
// sink = &Node{x} --> level=-1, x is accessible from sink via one "address of"
|
|
|
|
|
// sink = &Node{&Node{x}} --> level=-2, x is accessible from sink via two "address of"
|
|
|
|
|
// sink = &Node{&Node{x.left}} --> level=-1, but x is NOT accessible from sink because it was indirected and then copied.
|
|
|
|
|
// (The copy operations are sometimes implicit in the source code; in this case,
|
|
|
|
|
// value of x.left was copied into a field of a newly allocated Node)
|
|
|
|
|
//
|
|
|
|
|
// There's one of these for each Node, and the integer values
|
|
|
|
|
// rarely exceed even what can be stored in 4 bits, never mind 8.
|
|
|
|
|
type Level struct {
|
|
|
|
|
value, suffixValue int8
|
|
|
|
|
}
|
2015-03-05 13:57:36 -05: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 16:36:15 -04:00
|
|
|
func (l Level) int() int {
|
|
|
|
|
return int(l.value)
|
2015-02-13 14:40:36 -05: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 16:36:15 -04:00
|
|
|
func levelFrom(i int) Level {
|
|
|
|
|
if i <= MinLevel {
|
|
|
|
|
return Level{value: MinLevel}
|
|
|
|
|
}
|
|
|
|
|
return Level{value: int8(i)}
|
|
|
|
|
}
|
2015-02-13 14:40:36 -05: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 16:36:15 -04:00
|
|
|
func satInc8(x int8) int8 {
|
|
|
|
|
if x == 127 {
|
|
|
|
|
return 127
|
|
|
|
|
}
|
|
|
|
|
return x + 1
|
|
|
|
|
}
|
2015-02-13 14:40:36 -05: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 16:36:15 -04:00
|
|
|
func min8(a, b int8) int8 {
|
|
|
|
|
if a < b {
|
|
|
|
|
return a
|
|
|
|
|
}
|
|
|
|
|
return b
|
|
|
|
|
}
|
2015-02-13 14:40:36 -05: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 16:36:15 -04:00
|
|
|
func max8(a, b int8) int8 {
|
|
|
|
|
if a > b {
|
|
|
|
|
return a
|
2015-02-13 14:40:36 -05: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 16:36:15 -04:00
|
|
|
return b
|
|
|
|
|
}
|
2015-02-13 14:40:36 -05: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 16:36:15 -04:00
|
|
|
// inc returns the level l + 1, representing the effect of an indirect (*) operation.
|
|
|
|
|
func (l Level) inc() Level {
|
|
|
|
|
if l.value <= MinLevel {
|
|
|
|
|
return Level{value: MinLevel}
|
2015-02-13 14:40:36 -05: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 16:36:15 -04:00
|
|
|
return Level{value: satInc8(l.value), suffixValue: satInc8(l.suffixValue)}
|
2015-02-13 14:40:36 -05: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 16:36:15 -04:00
|
|
|
// dec returns the level l - 1, representing the effect of an address-of (&) operation.
|
|
|
|
|
func (l Level) dec() Level {
|
|
|
|
|
if l.value <= MinLevel {
|
|
|
|
|
return Level{value: MinLevel}
|
2015-02-13 14:40:36 -05: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 16:36:15 -04:00
|
|
|
return Level{value: l.value - 1, suffixValue: l.suffixValue - 1}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// copy returns the level for a copy of a value with level l.
|
|
|
|
|
func (l Level) copy() Level {
|
|
|
|
|
return Level{value: l.value, suffixValue: max8(l.suffixValue, 0)}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (l1 Level) min(l2 Level) Level {
|
|
|
|
|
return Level{
|
|
|
|
|
value: min8(l1.value, l2.value),
|
|
|
|
|
suffixValue: min8(l1.suffixValue, l2.suffixValue)}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// guaranteedDereference returns the number of dereferences
|
|
|
|
|
// applied to a pointer before addresses are taken/generated.
|
|
|
|
|
// This is the maximum level computed from path suffixes starting
|
|
|
|
|
// with copies where paths flow from destination to source.
|
|
|
|
|
func (l Level) guaranteedDereference() int {
|
|
|
|
|
return int(l.suffixValue)
|
|
|
|
|
}
|
|
|
|
|
|
2016-02-29 10:43:18 -05:00
|
|
|
// An EscStep documents one step in the path from memory
|
|
|
|
|
// that is heap allocated to the (alleged) reason for the
|
|
|
|
|
// heap allocation.
|
|
|
|
|
type EscStep struct {
|
|
|
|
|
src, dst *Node // the endpoints of this edge in the escape-to-heap chain.
|
2016-10-21 12:01:52 -04:00
|
|
|
where *Node // sometimes the endpoints don't match source locations; set 'where' to make that right
|
2016-02-29 10:43:18 -05:00
|
|
|
parent *EscStep // used in flood to record path
|
|
|
|
|
why string // explanation for this step in the escape-to-heap chain
|
|
|
|
|
busy bool // used in prevent to snip cycles.
|
|
|
|
|
}
|
|
|
|
|
|
2015-05-26 23:42:41 -04:00
|
|
|
type NodeEscState struct {
|
cmd/compile: better modeling of escape across loop levels
Brief background on "why heap allocate". Things can be
forced to the heap for the following reasons:
1) address published, hence lifetime unknown.
2) size unknown/too large, cannot be stack allocated
3) multiplicity unknown/too large, cannot be stack allocated
4) reachable from heap (not necessarily published)
The bug here is a case of failing to enforce 4) when an
object Y was reachable from a heap allocation X forced
because of 3). It was found in the case of a closure
allocated within a loop (X) and assigned to a variable
outside the loop (multiplicity unknown) where the closure
also captured a map (Y) declared outside the loop (reachable
from heap). Note the variable declared outside the loop (Y)
is not published, has known size, and known multiplicity
(one). The only reason for heap allocation is that it was
reached from a heap allocated item (X), but because that was
not forced by publication, it has to be tracked by loop
level, but escape-loop level was not tracked and thus a bug
results.
The fix is that when a heap allocation is newly discovered,
use its looplevel as the minimum loop level for downstream
escape flooding.
Every attempt to generalize this bug to X-in-loop-
references-Y-outside loop succeeded, so the fix was aimed
to be general. Anywhere that loop level forces heap
allocation, the loop level is tracked. This is not yet
tested for all possible X and Y, but it is correctness-
conservative and because it caused only one trivial
regression in the escape tests, it is probably also
performance-conservative.
The new test checks the following:
1) in the map case, that if fn escapes, so does the map.
2) in the map case, if fn does not escape, neither does the map.
3) in the &x case, that if fn escapes, so does &x.
4) in the &x case, if fn does not escape, neither does &x.
Fixes #13799.
Change-Id: Ie280bef2bb86ec869c7c206789d0b68f080c3fdb
Reviewed-on: https://go-review.googlesource.com/18234
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2016-01-04 16:44:20 -05:00
|
|
|
Curfn *Node
|
2016-10-12 11:34:47 +09:00
|
|
|
Flowsrc []EscStep // flow(this, src)
|
|
|
|
|
Retval Nodes // on OCALLxxx, list of dummy return values
|
|
|
|
|
Loopdepth int32 // -1: global, 0: return variables, 1:function top level, increased inside function for every loop or label to mark scopes
|
|
|
|
|
Level Level
|
cmd/compile: better modeling of escape across loop levels
Brief background on "why heap allocate". Things can be
forced to the heap for the following reasons:
1) address published, hence lifetime unknown.
2) size unknown/too large, cannot be stack allocated
3) multiplicity unknown/too large, cannot be stack allocated
4) reachable from heap (not necessarily published)
The bug here is a case of failing to enforce 4) when an
object Y was reachable from a heap allocation X forced
because of 3). It was found in the case of a closure
allocated within a loop (X) and assigned to a variable
outside the loop (multiplicity unknown) where the closure
also captured a map (Y) declared outside the loop (reachable
from heap). Note the variable declared outside the loop (Y)
is not published, has known size, and known multiplicity
(one). The only reason for heap allocation is that it was
reached from a heap allocated item (X), but because that was
not forced by publication, it has to be tracked by loop
level, but escape-loop level was not tracked and thus a bug
results.
The fix is that when a heap allocation is newly discovered,
use its looplevel as the minimum loop level for downstream
escape flooding.
Every attempt to generalize this bug to X-in-loop-
references-Y-outside loop succeeded, so the fix was aimed
to be general. Anywhere that loop level forces heap
allocation, the loop level is tracked. This is not yet
tested for all possible X and Y, but it is correctness-
conservative and because it caused only one trivial
regression in the escape tests, it is probably also
performance-conservative.
The new test checks the following:
1) in the map case, that if fn escapes, so does the map.
2) in the map case, if fn does not escape, neither does the map.
3) in the &x case, that if fn escapes, so does &x.
4) in the &x case, if fn does not escape, neither does &x.
Fixes #13799.
Change-Id: Ie280bef2bb86ec869c7c206789d0b68f080c3fdb
Reviewed-on: https://go-review.googlesource.com/18234
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2016-01-04 16:44:20 -05:00
|
|
|
Walkgen uint32
|
|
|
|
|
Maxextraloopdepth int32
|
2015-05-26 23:42:41 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (e *EscState) nodeEscState(n *Node) *NodeEscState {
|
2015-05-27 00:47:05 -04:00
|
|
|
if nE, ok := n.Opt().(*NodeEscState); ok {
|
2015-05-26 23:42:41 -04:00
|
|
|
return nE
|
|
|
|
|
}
|
2015-05-27 00:47:05 -04:00
|
|
|
if n.Opt() != nil {
|
2015-08-30 23:10:03 +02:00
|
|
|
Fatalf("nodeEscState: opt in use (%T)", n.Opt())
|
2015-05-26 23:42:41 -04:00
|
|
|
}
|
2016-10-12 11:34:47 +09:00
|
|
|
nE := &NodeEscState{
|
|
|
|
|
Curfn: Curfn,
|
|
|
|
|
}
|
2015-05-27 00:47:05 -04:00
|
|
|
n.SetOpt(nE)
|
2015-05-26 23:42:41 -04:00
|
|
|
e.opts = append(e.opts, n)
|
|
|
|
|
return nE
|
|
|
|
|
}
|
|
|
|
|
|
2015-05-27 07:31:56 -04:00
|
|
|
func (e *EscState) track(n *Node) {
|
|
|
|
|
if Curfn == nil {
|
2015-08-30 23:10:03 +02:00
|
|
|
Fatalf("EscState.track: Curfn nil")
|
2015-05-27 07:31:56 -04:00
|
|
|
}
|
|
|
|
|
n.Esc = EscNone // until proven otherwise
|
|
|
|
|
nE := e.nodeEscState(n)
|
2016-10-12 11:34:47 +09:00
|
|
|
nE.Loopdepth = e.loopdepth
|
2016-03-03 17:38:14 -08:00
|
|
|
e.noesc = append(e.noesc, n)
|
2015-05-27 07:31:56 -04: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 16:36:15 -04:00
|
|
|
// Escape constants are numbered in order of increasing "escapiness"
|
2016-03-01 23:21:55 +00:00
|
|
|
// to help make inferences be monotonic. With the exception of
|
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 16:36:15 -04:00
|
|
|
// EscNever which is sticky, eX < eY means that eY is more exposed
|
|
|
|
|
// than eX, and hence replaces it in a conservative analysis.
|
|
|
|
|
const (
|
2016-10-26 11:44:26 +09:00
|
|
|
EscUnknown = iota
|
|
|
|
|
EscNone // Does not escape to heap, result, or parameters.
|
|
|
|
|
EscReturn // Is returned or reachable from returned.
|
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 16:36:15 -04:00
|
|
|
EscHeap // Reachable from the heap
|
|
|
|
|
EscNever // By construction will not escape.
|
|
|
|
|
EscBits = 3
|
|
|
|
|
EscMask = (1 << EscBits) - 1
|
|
|
|
|
EscContentEscapes = 1 << EscBits // value obtained by indirect of parameter escapes to heap
|
|
|
|
|
EscReturnBits = EscBits + 1
|
|
|
|
|
// Node.esc encoding = | escapeReturnEncoding:(width-4) | contentEscapes:1 | escEnum:3
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
// escMax returns the maximum of an existing escape value
|
|
|
|
|
// (and its additional parameter flow flags) and a new escape type.
|
|
|
|
|
func escMax(e, etype uint16) uint16 {
|
2016-10-26 11:44:26 +09:00
|
|
|
if e&EscMask >= EscHeap {
|
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 16:36:15 -04:00
|
|
|
// normalize
|
2015-05-01 11:16:35 -04:00
|
|
|
if e&^EscMask != 0 {
|
2016-10-26 11:44:26 +09:00
|
|
|
Fatalf("Escape information had unexpected return encoding bits (w/ EscHeap, EscNever), e&EscMask=%v", e&EscMask)
|
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 16:36:15 -04:00
|
|
|
}
|
2015-02-13 14:40:36 -05: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 16:36:15 -04:00
|
|
|
if e&EscMask > etype {
|
|
|
|
|
return e
|
|
|
|
|
}
|
|
|
|
|
if etype == EscNone || etype == EscReturn {
|
|
|
|
|
return (e &^ EscMask) | etype
|
|
|
|
|
}
|
|
|
|
|
return etype
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// For each input parameter to a function, the escapeReturnEncoding describes
|
2016-03-01 23:21:55 +00:00
|
|
|
// how the parameter may leak to the function's outputs. This is currently the
|
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 16:36:15 -04:00
|
|
|
// "level" of the leak where level is 0 or larger (negative level means stored into
|
|
|
|
|
// something whose address is returned -- but that implies stored into the heap,
|
|
|
|
|
// hence EscHeap, which means that the details are not currently relevant. )
|
|
|
|
|
const (
|
2015-09-13 23:57:28 +02:00
|
|
|
bitsPerOutputInTag = 3 // For each output, the number of bits for a tag
|
|
|
|
|
bitsMaskForTag = uint16(1<<bitsPerOutputInTag) - 1 // The bit mask to extract a single tag.
|
|
|
|
|
maxEncodedLevel = int(bitsMaskForTag - 1) // The largest level that can be stored in a tag.
|
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 16:36:15 -04:00
|
|
|
)
|
|
|
|
|
|
|
|
|
|
type EscState struct {
|
|
|
|
|
// Fake node that all
|
|
|
|
|
// - return values and output variables
|
|
|
|
|
// - parameters on imported functions not marked 'safe'
|
|
|
|
|
// - assignments to global variables
|
|
|
|
|
// flow to.
|
|
|
|
|
theSink Node
|
|
|
|
|
|
2016-03-03 17:38:14 -08:00
|
|
|
dsts []*Node // all dst nodes
|
|
|
|
|
loopdepth int32 // for detecting nested loop scopes
|
|
|
|
|
pdepth int // for debug printing in recursions.
|
|
|
|
|
dstcount int // diagnostic
|
|
|
|
|
edgecount int // diagnostic
|
|
|
|
|
noesc []*Node // list of possible non-escaping nodes, for printing
|
|
|
|
|
recursive bool // recursive function or group of mutually recursive functions.
|
|
|
|
|
opts []*Node // nodes with .Opt initialized
|
2015-05-27 00:44:05 -04:00
|
|
|
walkgen uint32
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
2016-10-12 11:34:47 +09:00
|
|
|
func newEscState(recursive bool) *EscState {
|
|
|
|
|
e := new(EscState)
|
|
|
|
|
e.theSink.Op = ONAME
|
|
|
|
|
e.theSink.Orig = &e.theSink
|
|
|
|
|
e.theSink.Class = PEXTERN
|
|
|
|
|
e.theSink.Sym = lookup(".sink")
|
|
|
|
|
e.nodeEscState(&e.theSink).Loopdepth = -1
|
|
|
|
|
e.recursive = recursive
|
|
|
|
|
return e
|
|
|
|
|
}
|
|
|
|
|
|
2016-02-29 10:43:18 -05:00
|
|
|
func (e *EscState) stepWalk(dst, src *Node, why string, parent *EscStep) *EscStep {
|
|
|
|
|
// TODO: keep a cache of these, mark entry/exit in escwalk to avoid allocation
|
|
|
|
|
// Or perhaps never mind, since it is disabled unless printing is on.
|
|
|
|
|
// We may want to revisit this, since the EscStep nodes would make
|
|
|
|
|
// an excellent replacement for the poorly-separated graph-build/graph-flood
|
|
|
|
|
// stages.
|
|
|
|
|
if Debug['m'] == 0 {
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
return &EscStep{src: src, dst: dst, why: why, parent: parent}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (e *EscState) stepAssign(step *EscStep, dst, src *Node, why string) *EscStep {
|
|
|
|
|
if Debug['m'] == 0 {
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
if step != nil { // Caller may have known better.
|
2016-10-21 12:01:52 -04:00
|
|
|
if step.why == "" {
|
|
|
|
|
step.why = why
|
|
|
|
|
}
|
|
|
|
|
if step.dst == nil {
|
|
|
|
|
step.dst = dst
|
|
|
|
|
}
|
|
|
|
|
if step.src == nil {
|
|
|
|
|
step.src = src
|
|
|
|
|
}
|
2016-02-29 10:43:18 -05:00
|
|
|
return step
|
|
|
|
|
}
|
|
|
|
|
return &EscStep{src: src, dst: dst, why: why}
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-21 12:01:52 -04:00
|
|
|
func (e *EscState) stepAssignWhere(dst, src *Node, why string, where *Node) *EscStep {
|
|
|
|
|
if Debug['m'] == 0 {
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
return &EscStep{src: src, dst: dst, why: why, where: where}
|
|
|
|
|
}
|
|
|
|
|
|
2015-06-03 14:16:01 -04:00
|
|
|
// funcSym returns fn.Func.Nname.Sym if no nils are encountered along the way.
|
2015-05-27 10:42:55 -04:00
|
|
|
func funcSym(fn *Node) *Sym {
|
|
|
|
|
if fn == nil || fn.Func.Nname == nil {
|
2015-05-15 12:19:07 -04:00
|
|
|
return nil
|
|
|
|
|
}
|
2015-05-27 10:42:55 -04:00
|
|
|
return fn.Func.Nname.Sym
|
2015-05-15 12:19:07 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// curfnSym returns n.Curfn.Nname.Sym if no nils are encountered along the way.
|
2015-05-27 07:31:56 -04:00
|
|
|
func (e *EscState) curfnSym(n *Node) *Sym {
|
|
|
|
|
nE := e.nodeEscState(n)
|
|
|
|
|
return funcSym(nE.Curfn)
|
2015-05-15 12:19:07 -04:00
|
|
|
}
|
|
|
|
|
|
2015-09-05 12:30:13 +10:00
|
|
|
func escAnalyze(all []*Node, recursive bool) {
|
2016-10-12 11:34:47 +09:00
|
|
|
e := newEscState(recursive)
|
2015-02-13 14:40:36 -05:00
|
|
|
|
2016-03-23 16:35:50 +01:00
|
|
|
for _, n := range all {
|
|
|
|
|
if n.Op == ODCLFUNC {
|
2015-09-05 12:30:13 +10:00
|
|
|
n.Esc = EscFuncPlanned
|
2017-03-28 17:55:26 -04:00
|
|
|
if Debug['m'] > 3 {
|
|
|
|
|
Dump("escAnalyze", n)
|
|
|
|
|
}
|
|
|
|
|
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// flow-analyze functions
|
2016-03-23 16:35:50 +01:00
|
|
|
for _, n := range all {
|
|
|
|
|
if n.Op == ODCLFUNC {
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escfunc(n)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-12 11:34:47 +09:00
|
|
|
// print("escapes: %d e.dsts, %d edges\n", e.dstcount, e.edgecount);
|
2015-02-13 14:40:36 -05:00
|
|
|
|
|
|
|
|
// visit the upstream of each dst, mark address nodes with
|
|
|
|
|
// addrescapes, mark parameters unsafe
|
2016-10-08 16:45:58 -04:00
|
|
|
escapes := make([]uint16, len(e.dsts))
|
|
|
|
|
for i, n := range e.dsts {
|
|
|
|
|
escapes[i] = n.Esc
|
|
|
|
|
}
|
2016-03-03 17:38:14 -08:00
|
|
|
for _, n := range e.dsts {
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escflood(n)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
2016-10-08 16:45:58 -04:00
|
|
|
for {
|
|
|
|
|
done := true
|
|
|
|
|
for i, n := range e.dsts {
|
|
|
|
|
if n.Esc != escapes[i] {
|
|
|
|
|
done = false
|
|
|
|
|
if Debug['m'] > 2 {
|
2016-12-07 17:40:46 -08:00
|
|
|
Warnl(n.Pos, "Reflooding %v %S", e.curfnSym(n), n)
|
2016-10-08 16:45:58 -04:00
|
|
|
}
|
|
|
|
|
escapes[i] = n.Esc
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escflood(n)
|
2016-10-08 16:45:58 -04:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if done {
|
|
|
|
|
break
|
|
|
|
|
}
|
|
|
|
|
}
|
2015-02-13 14:40:36 -05:00
|
|
|
|
|
|
|
|
// for all top level functions, tag the typenodes corresponding to the param nodes
|
2016-03-23 16:35:50 +01:00
|
|
|
for _, n := range all {
|
|
|
|
|
if n.Op == ODCLFUNC {
|
2016-10-12 11:34:47 +09:00
|
|
|
e.esctag(n)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if Debug['m'] != 0 {
|
2016-03-03 17:38:14 -08:00
|
|
|
for _, n := range e.noesc {
|
|
|
|
|
if n.Esc == EscNone {
|
2016-12-07 17:40:46 -08:00
|
|
|
Warnl(n.Pos, "%v %S does not escape", e.curfnSym(n), n)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2016-10-12 11:34:47 +09:00
|
|
|
|
2015-05-26 23:42:41 -04:00
|
|
|
for _, x := range e.opts {
|
2015-05-27 00:47:05 -04:00
|
|
|
x.SetOpt(nil)
|
2015-05-26 23:42:41 -04:00
|
|
|
}
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
2016-10-12 11:34:47 +09:00
|
|
|
func (e *EscState) escfunc(fn *Node) {
|
|
|
|
|
// print("escfunc %N %s\n", fn.Func.Nname, e.recursive?"(recursive)":"");
|
|
|
|
|
if fn.Esc != EscFuncPlanned {
|
|
|
|
|
Fatalf("repeat escfunc %v", fn.Func.Nname)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
2016-10-12 11:34:47 +09:00
|
|
|
fn.Esc = EscFuncStarted
|
2015-02-13 14:40:36 -05:00
|
|
|
|
2015-02-23 16:07:24 -05:00
|
|
|
saveld := e.loopdepth
|
2015-02-13 14:40:36 -05:00
|
|
|
e.loopdepth = 1
|
2015-02-23 16:07:24 -05:00
|
|
|
savefn := Curfn
|
2016-10-12 11:34:47 +09:00
|
|
|
Curfn = fn
|
2015-02-13 14:40:36 -05:00
|
|
|
|
2016-02-25 10:35:19 -08:00
|
|
|
for _, ln := range Curfn.Func.Dcl {
|
|
|
|
|
if ln.Op != ONAME {
|
2015-02-13 14:40:36 -05:00
|
|
|
continue
|
|
|
|
|
}
|
2016-10-12 11:34:47 +09:00
|
|
|
lnE := e.nodeEscState(ln)
|
2016-02-25 10:35:19 -08:00
|
|
|
switch ln.Class {
|
2015-02-13 14:40:36 -05:00
|
|
|
// out params are in a loopdepth between the sink and all local variables
|
|
|
|
|
case PPARAMOUT:
|
2016-10-12 11:34:47 +09:00
|
|
|
lnE.Loopdepth = 0
|
2015-02-13 14:40:36 -05:00
|
|
|
|
|
|
|
|
case PPARAM:
|
2016-10-12 11:34:47 +09:00
|
|
|
lnE.Loopdepth = 1
|
2016-02-25 10:35:19 -08:00
|
|
|
if ln.Type != nil && !haspointers(ln.Type) {
|
2015-02-13 14:40:36 -05:00
|
|
|
break
|
|
|
|
|
}
|
2017-02-27 19:56:38 +02:00
|
|
|
if Curfn.Nbody.Len() == 0 && !Curfn.Noescape() {
|
2016-02-25 10:35:19 -08:00
|
|
|
ln.Esc = EscHeap
|
2015-02-13 14:40:36 -05:00
|
|
|
} else {
|
2016-02-25 10:35:19 -08:00
|
|
|
ln.Esc = EscNone // prime for escflood later
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
2016-03-03 17:38:14 -08:00
|
|
|
e.noesc = append(e.noesc, ln)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// in a mutually recursive group we lose track of the return values
|
2015-02-17 22:13:49 -05:00
|
|
|
if e.recursive {
|
2016-02-25 10:35:19 -08:00
|
|
|
for _, ln := range Curfn.Func.Dcl {
|
|
|
|
|
if ln.Op == ONAME && ln.Class == PPARAMOUT {
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escflows(&e.theSink, ln, e.stepAssign(nil, ln, ln, "returned from recursive function"))
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escloopdepthlist(Curfn.Nbody)
|
|
|
|
|
e.esclist(Curfn.Nbody, Curfn)
|
2015-02-13 14:40:36 -05:00
|
|
|
Curfn = savefn
|
|
|
|
|
e.loopdepth = saveld
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-12 11:34:47 +09:00
|
|
|
// Mark labels that have no backjumps to them as not increasing e.loopdepth.
|
|
|
|
|
// Walk hasn't generated (goto|label).Left.Sym.Label yet, so we'll cheat
|
2016-03-01 23:21:55 +00:00
|
|
|
// and set it to one of the following two. Then in esc we'll clear it again.
|
2016-10-26 17:14:35 -07:00
|
|
|
var (
|
|
|
|
|
looping Node
|
|
|
|
|
nonlooping Node
|
|
|
|
|
)
|
2015-02-13 14:40:36 -05:00
|
|
|
|
2016-10-12 11:34:47 +09:00
|
|
|
func (e *EscState) escloopdepthlist(l Nodes) {
|
2016-03-08 15:10:26 -08:00
|
|
|
for _, n := range l.Slice() {
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escloopdepth(n)
|
2016-02-27 14:31:33 -08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-12 11:34:47 +09:00
|
|
|
func (e *EscState) escloopdepth(n *Node) {
|
2015-02-13 14:40:36 -05:00
|
|
|
if n == nil {
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escloopdepthlist(n.Ninit)
|
2015-02-13 14:40:36 -05:00
|
|
|
|
|
|
|
|
switch n.Op {
|
|
|
|
|
case OLABEL:
|
2015-02-17 22:13:49 -05:00
|
|
|
if n.Left == nil || n.Left.Sym == nil {
|
2016-08-31 15:22:36 -07:00
|
|
|
Fatalf("esc:label without label: %+v", n)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Walk will complain about this label being already defined, but that's not until
|
|
|
|
|
// after escape analysis. in the future, maybe pull label & goto analysis out of walk and put before esc
|
2016-10-12 11:34:47 +09:00
|
|
|
// if(n.Left.Sym.Label != nil)
|
2015-02-13 14:40:36 -05:00
|
|
|
// fatal("escape analysis messed up analyzing label: %+N", n);
|
|
|
|
|
n.Left.Sym.Label = &nonlooping
|
|
|
|
|
|
|
|
|
|
case OGOTO:
|
2015-02-17 22:13:49 -05:00
|
|
|
if n.Left == nil || n.Left.Sym == nil {
|
2016-08-31 15:22:36 -07:00
|
|
|
Fatalf("esc:goto without label: %+v", n)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// If we come past one that's uninitialized, this must be a (harmless) forward jump
|
|
|
|
|
// but if it's set to nonlooping the label must have preceded this goto.
|
|
|
|
|
if n.Left.Sym.Label == &nonlooping {
|
|
|
|
|
n.Left.Sym.Label = &looping
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escloopdepth(n.Left)
|
|
|
|
|
e.escloopdepth(n.Right)
|
|
|
|
|
e.escloopdepthlist(n.List)
|
|
|
|
|
e.escloopdepthlist(n.Nbody)
|
|
|
|
|
e.escloopdepthlist(n.Rlist)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
2016-10-12 11:34:47 +09:00
|
|
|
func (e *EscState) esclist(l Nodes, parent *Node) {
|
2016-03-08 15:10:26 -08:00
|
|
|
for _, n := range l.Slice() {
|
2016-10-12 11:34:47 +09:00
|
|
|
e.esc(n, parent)
|
2016-02-27 14:31:33 -08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-12 11:34:47 +09:00
|
|
|
func (e *EscState) esc(n *Node, parent *Node) {
|
2015-02-13 14:40:36 -05:00
|
|
|
if n == nil {
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
2016-03-02 17:34:42 -08:00
|
|
|
lno := setlineno(n)
|
2015-02-13 14:40:36 -05:00
|
|
|
|
|
|
|
|
// ninit logically runs at a different loopdepth than the rest of the for loop.
|
2016-10-12 11:34:47 +09:00
|
|
|
e.esclist(n.Ninit, n)
|
2015-02-13 14:40:36 -05:00
|
|
|
|
2017-02-02 11:53:41 -05:00
|
|
|
if n.Op == OFOR || n.Op == OFORUNTIL || n.Op == ORANGE {
|
2015-02-13 14:40:36 -05:00
|
|
|
e.loopdepth++
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// type switch variables have no ODCL.
|
|
|
|
|
// process type switch as declaration.
|
|
|
|
|
// must happen before processing of switch body,
|
|
|
|
|
// so before recursion.
|
2015-05-26 21:30:20 -04:00
|
|
|
if n.Op == OSWITCH && n.Left != nil && n.Left.Op == OTYPESW {
|
2017-03-14 08:18:11 -07:00
|
|
|
for _, cas := range n.List.Slice() { // cases
|
2016-03-03 17:38:14 -08:00
|
|
|
// it.N().Rlist is the variable per case
|
2017-03-14 08:18:11 -07:00
|
|
|
if cas.Rlist.Len() != 0 {
|
|
|
|
|
e.nodeEscState(cas.Rlist.First()).Loopdepth = e.loopdepth
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2015-05-20 15:16:34 -04:00
|
|
|
// Big stuff escapes unconditionally
|
|
|
|
|
// "Big" conditions that were scattered around in walk have been gathered here
|
2016-02-19 12:06:31 -05:00
|
|
|
if n.Esc != EscHeap && n.Type != nil &&
|
|
|
|
|
(n.Type.Width > MaxStackVarSize ||
|
2016-05-18 13:04:00 -07:00
|
|
|
(n.Op == ONEW || n.Op == OPTRLIT) && n.Type.Elem().Width >= 1<<16 ||
|
2016-02-19 12:06:31 -05:00
|
|
|
n.Op == OMAKESLICE && !isSmallMakeSlice(n)) {
|
2016-02-29 10:43:18 -05:00
|
|
|
if Debug['m'] > 2 {
|
2016-12-07 17:40:46 -08:00
|
|
|
Warnl(n.Pos, "%v is too large for stack", n)
|
2015-05-20 15:16:34 -04:00
|
|
|
}
|
|
|
|
|
n.Esc = EscHeap
|
|
|
|
|
addrescapes(n)
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassignSinkWhy(n, n, "too large for stack") // TODO category: tooLarge
|
2015-05-20 15:16:34 -04:00
|
|
|
}
|
|
|
|
|
|
2017-02-27 11:37:54 -08:00
|
|
|
if n.Op == OIF && Isconst(n.Left, CTBOOL) {
|
|
|
|
|
// Don't examine dead code.
|
|
|
|
|
if n.Left.Bool() {
|
|
|
|
|
e.esclist(n.Nbody, n)
|
|
|
|
|
} else {
|
|
|
|
|
e.esclist(n.Rlist, n)
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
e.esc(n.Left, n)
|
|
|
|
|
e.esc(n.Right, n)
|
|
|
|
|
e.esclist(n.Nbody, n)
|
|
|
|
|
e.esclist(n.List, n)
|
|
|
|
|
e.esclist(n.Rlist, n)
|
|
|
|
|
}
|
2015-02-13 14:40:36 -05:00
|
|
|
|
2017-02-02 11:53:41 -05:00
|
|
|
if n.Op == OFOR || n.Op == OFORUNTIL || n.Op == ORANGE {
|
2015-02-13 14:40:36 -05:00
|
|
|
e.loopdepth--
|
|
|
|
|
}
|
|
|
|
|
|
2016-02-29 10:43:18 -05:00
|
|
|
if Debug['m'] > 2 {
|
2016-03-02 11:30:29 -08:00
|
|
|
fmt.Printf("%v:[%d] %v esc: %v\n", linestr(lineno), e.loopdepth, funcSym(Curfn), n)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
switch n.Op {
|
|
|
|
|
// Record loop depth at declaration.
|
|
|
|
|
case ODCL:
|
|
|
|
|
if n.Left != nil {
|
2016-10-12 11:34:47 +09:00
|
|
|
e.nodeEscState(n.Left).Loopdepth = e.loopdepth
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
case OLABEL:
|
|
|
|
|
if n.Left.Sym.Label == &nonlooping {
|
2016-02-29 10:43:18 -05:00
|
|
|
if Debug['m'] > 2 {
|
2016-03-02 11:30:29 -08:00
|
|
|
fmt.Printf("%v:%v non-looping label\n", linestr(lineno), n)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
} else if n.Left.Sym.Label == &looping {
|
2016-02-29 10:43:18 -05:00
|
|
|
if Debug['m'] > 2 {
|
2016-03-02 11:30:29 -08:00
|
|
|
fmt.Printf("%v: %v looping label\n", linestr(lineno), n)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
e.loopdepth++
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// See case OLABEL in escloopdepth above
|
2016-10-12 11:34:47 +09:00
|
|
|
// else if(n.Left.Sym.Label == nil)
|
2015-02-13 14:40:36 -05:00
|
|
|
// fatal("escape analysis missed or messed up a label: %+N", n);
|
|
|
|
|
|
|
|
|
|
n.Left.Sym.Label = nil
|
|
|
|
|
|
|
|
|
|
case ORANGE:
|
2016-03-08 15:10:26 -08:00
|
|
|
if n.List.Len() >= 2 {
|
2015-09-28 16:13:57 -04:00
|
|
|
// Everything but fixed array is a dereference.
|
|
|
|
|
|
|
|
|
|
// If fixed array is really the address of fixed array,
|
|
|
|
|
// it is also a dereference, because it is implicitly
|
|
|
|
|
// dereferenced (see #12588)
|
2016-03-30 14:45:47 -07:00
|
|
|
if n.Type.IsArray() &&
|
2016-09-15 14:34:20 +10:00
|
|
|
!(n.Right.Type.IsPtr() && eqtype(n.Right.Type.Elem(), n.Type)) {
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassignWhyWhere(n.List.Second(), n.Right, "range", n)
|
2015-05-15 12:19:07 -04:00
|
|
|
} else {
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassignDereference(n.List.Second(), n.Right, e.stepAssignWhere(n.List.Second(), n.Right, "range-deref", n))
|
2015-05-15 12:19:07 -04:00
|
|
|
}
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
case OSWITCH:
|
2015-05-26 21:30:20 -04:00
|
|
|
if n.Left != nil && n.Left.Op == OTYPESW {
|
2017-03-14 08:18:11 -07:00
|
|
|
for _, cas := range n.List.Slice() {
|
2015-05-26 21:30:20 -04:00
|
|
|
// cases
|
2015-05-27 10:43:53 -04:00
|
|
|
// n.Left.Right is the argument of the .(type),
|
2016-03-03 17:38:14 -08:00
|
|
|
// it.N().Rlist is the variable per case
|
2017-03-14 08:18:11 -07:00
|
|
|
if cas.Rlist.Len() != 0 {
|
|
|
|
|
e.escassignWhyWhere(cas.Rlist.First(), n.Left.Right, "switch case", n)
|
2015-05-27 10:43:53 -04:00
|
|
|
}
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-09-24 21:38:58 +02:00
|
|
|
// Filter out the following special case.
|
2015-02-13 14:40:36 -05:00
|
|
|
//
|
|
|
|
|
// func (b *Buffer) Foo() {
|
|
|
|
|
// n, m := ...
|
|
|
|
|
// b.buf = b.buf[n:m]
|
|
|
|
|
// }
|
|
|
|
|
//
|
|
|
|
|
// This assignment is a no-op for escape analysis,
|
|
|
|
|
// it does not store any new pointers into b that were not already there.
|
|
|
|
|
// However, without this special case b will escape, because we assign to OIND/ODOTPTR.
|
2016-12-19 10:30:44 -08:00
|
|
|
case OAS, OASOP:
|
2015-03-05 13:57:36 -05:00
|
|
|
if (n.Left.Op == OIND || n.Left.Op == ODOTPTR) && n.Left.Left.Op == ONAME && // dst is ONAME dereference
|
|
|
|
|
(n.Right.Op == OSLICE || n.Right.Op == OSLICE3 || n.Right.Op == OSLICESTR) && // src is slice operation
|
|
|
|
|
(n.Right.Left.Op == OIND || n.Right.Left.Op == ODOTPTR) && n.Right.Left.Left.Op == ONAME && // slice is applied to ONAME dereference
|
|
|
|
|
n.Left.Left == n.Right.Left.Left { // dst and src reference the same base ONAME
|
2015-02-13 14:40:36 -05:00
|
|
|
|
|
|
|
|
// Here we also assume that the statement will not contain calls,
|
|
|
|
|
// that is, that order will move any calls to init.
|
|
|
|
|
// Otherwise base ONAME value could change between the moments
|
|
|
|
|
// when we evaluate it for dst and for src.
|
|
|
|
|
//
|
|
|
|
|
// Note, this optimization does not apply to OSLICEARR,
|
|
|
|
|
// because it does introduce a new pointer into b that was not already there
|
|
|
|
|
// (pointer to b itself). After such assignment, if b contents escape,
|
|
|
|
|
// b escapes as well. If we ignore such OSLICEARR, we will conclude
|
|
|
|
|
// that b does not escape when b contents do.
|
|
|
|
|
if Debug['m'] != 0 {
|
2016-12-07 17:40:46 -08:00
|
|
|
Warnl(n.Pos, "%v ignoring self-assignment to %S", e.curfnSym(n), n.Left)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
break
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassign(n.Left, n.Right, e.stepAssignWhere(nil, nil, "", n))
|
2015-02-13 14:40:36 -05:00
|
|
|
|
|
|
|
|
case OAS2: // x,y = a,b
|
2016-03-08 15:10:26 -08:00
|
|
|
if n.List.Len() == n.Rlist.Len() {
|
2016-03-09 12:39:36 -08:00
|
|
|
rs := n.Rlist.Slice()
|
|
|
|
|
for i, n := range n.List.Slice() {
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassignWhyWhere(n, rs[i], "assign-pair", n)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-02-29 10:43:18 -05:00
|
|
|
case OAS2RECV: // v, ok = <-ch
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassignWhyWhere(n.List.First(), n.Rlist.First(), "assign-pair-receive", n)
|
2016-02-29 10:43:18 -05:00
|
|
|
case OAS2MAPR: // v, ok = m[k]
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassignWhyWhere(n.List.First(), n.Rlist.First(), "assign-pair-mapr", n)
|
2016-02-29 10:43:18 -05:00
|
|
|
case OAS2DOTTYPE: // v, ok = x.(type)
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassignWhyWhere(n.List.First(), n.Rlist.First(), "assign-pair-dot-type", n)
|
2015-02-13 14:40:36 -05:00
|
|
|
|
|
|
|
|
case OSEND: // ch <- x
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassignSinkWhy(n, n.Right, "send")
|
2015-02-13 14:40:36 -05:00
|
|
|
|
|
|
|
|
case ODEFER:
|
|
|
|
|
if e.loopdepth == 1 { // top level
|
|
|
|
|
break
|
|
|
|
|
}
|
2015-03-05 13:57:36 -05:00
|
|
|
// arguments leak out of scope
|
|
|
|
|
// TODO: leak to a dummy node instead
|
2016-03-17 20:40:02 +01:00
|
|
|
// defer f(x) - f and x escape
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassignSinkWhy(n, n.Left.Left, "defer func")
|
|
|
|
|
e.escassignSinkWhy(n, n.Left.Right, "defer func ...") // ODDDARG for call
|
2017-03-14 08:18:11 -07:00
|
|
|
for _, arg := range n.Left.List.Slice() {
|
|
|
|
|
e.escassignSinkWhy(n, arg, "defer func arg")
|
2016-02-29 10:43:18 -05:00
|
|
|
}
|
2015-02-13 14:40:36 -05:00
|
|
|
|
|
|
|
|
case OPROC:
|
2015-03-05 13:57:36 -05:00
|
|
|
// go f(x) - f and x escape
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassignSinkWhy(n, n.Left.Left, "go func")
|
|
|
|
|
e.escassignSinkWhy(n, n.Left.Right, "go func ...") // ODDDARG for call
|
2017-03-14 08:18:11 -07:00
|
|
|
for _, arg := range n.Left.List.Slice() {
|
|
|
|
|
e.escassignSinkWhy(n, arg, "go func arg")
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
2015-04-01 09:38:44 -07:00
|
|
|
case OCALLMETH, OCALLFUNC, OCALLINTER:
|
2016-10-12 11:34:47 +09:00
|
|
|
e.esccall(n, parent)
|
2015-02-13 14:40:36 -05:00
|
|
|
|
2016-10-12 11:34:47 +09:00
|
|
|
// esccall already done on n.Rlist.First(). tie it's Retval to n.List
|
2015-02-13 14:40:36 -05:00
|
|
|
case OAS2FUNC: // x,y = f()
|
2016-10-12 11:34:47 +09:00
|
|
|
rs := e.nodeEscState(n.Rlist.First()).Retval.Slice()
|
2016-03-09 12:39:36 -08:00
|
|
|
for i, n := range n.List.Slice() {
|
|
|
|
|
if i >= len(rs) {
|
|
|
|
|
break
|
|
|
|
|
}
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassignWhyWhere(n, rs[i], "assign-pair-func-call", n)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
2016-03-09 12:39:36 -08:00
|
|
|
if n.List.Len() != len(rs) {
|
2015-08-30 23:10:03 +02:00
|
|
|
Fatalf("esc oas2func")
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
case ORETURN:
|
2016-10-12 11:34:47 +09:00
|
|
|
retList := n.List
|
|
|
|
|
if retList.Len() == 1 && Curfn.Type.Results().NumFields() > 1 {
|
2015-02-13 14:40:36 -05:00
|
|
|
// OAS2FUNC in disguise
|
2016-10-12 11:34:47 +09:00
|
|
|
// esccall already done on n.List.First()
|
|
|
|
|
// tie e.nodeEscState(n.List.First()).Retval to Curfn.Func.Dcl PPARAMOUT's
|
|
|
|
|
retList = e.nodeEscState(n.List.First()).Retval
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
2016-03-09 12:39:36 -08:00
|
|
|
i := 0
|
2016-02-25 10:35:19 -08:00
|
|
|
for _, lrn := range Curfn.Func.Dcl {
|
2016-10-12 11:34:47 +09:00
|
|
|
if i >= retList.Len() {
|
2016-02-25 10:35:19 -08:00
|
|
|
break
|
|
|
|
|
}
|
|
|
|
|
if lrn.Op != ONAME || lrn.Class != PPARAMOUT {
|
2015-02-13 14:40:36 -05:00
|
|
|
continue
|
|
|
|
|
}
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassignWhyWhere(lrn, retList.Index(i), "return", n)
|
2016-03-09 12:39:36 -08:00
|
|
|
i++
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
2016-10-12 11:34:47 +09:00
|
|
|
if i < retList.Len() {
|
2015-08-30 23:10:03 +02:00
|
|
|
Fatalf("esc return list")
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Argument could leak through recover.
|
|
|
|
|
case OPANIC:
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassignSinkWhy(n, n.Left, "panic")
|
2015-02-13 14:40:36 -05:00
|
|
|
|
|
|
|
|
case OAPPEND:
|
2017-02-27 19:56:38 +02:00
|
|
|
if !n.Isddd() {
|
2016-02-29 10:43:18 -05:00
|
|
|
for _, nn := range n.List.Slice()[1:] {
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassignSinkWhy(n, nn, "appended to slice") // lose track of assign to dereference
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
2015-05-15 12:19:07 -04:00
|
|
|
} else {
|
|
|
|
|
// append(slice1, slice2...) -- slice2 itself does not escape, but contents do.
|
2016-03-08 15:10:26 -08:00
|
|
|
slice2 := n.List.Second()
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassignDereference(&e.theSink, slice2, e.stepAssignWhere(n, slice2, "appended slice...", n)) // lose track of assign of dereference
|
2016-02-29 10:43:18 -05:00
|
|
|
if Debug['m'] > 3 {
|
2016-12-07 17:40:46 -08:00
|
|
|
Warnl(n.Pos, "%v special treatment of append(slice1, slice2...) %S", e.curfnSym(n), n)
|
2015-05-15 12:19:07 -04:00
|
|
|
}
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassignDereference(&e.theSink, n.List.First(), e.stepAssignWhere(n, n.List.First(), "appendee slice", n)) // The original elements are now leaked, too
|
2015-02-13 14:40:36 -05:00
|
|
|
|
2015-06-24 17:31:57 -04:00
|
|
|
case OCOPY:
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassignDereference(&e.theSink, n.Right, e.stepAssignWhere(n, n.Right, "copied slice", n)) // lose track of assign of dereference
|
2015-06-24 17:31:57 -04:00
|
|
|
|
2015-04-01 09:38:44 -07:00
|
|
|
case OCONV, OCONVNOP:
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassignWhyWhere(n, n.Left, "converted", n)
|
2015-02-19 16:27:32 +03:00
|
|
|
|
|
|
|
|
case OCONVIFACE:
|
2015-05-27 07:31:56 -04:00
|
|
|
e.track(n)
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassignWhyWhere(n, n.Left, "interface-converted", n)
|
2015-02-13 14:40:36 -05:00
|
|
|
|
|
|
|
|
case OARRAYLIT:
|
2016-06-19 07:20:28 -07:00
|
|
|
// Link values to array
|
2017-03-14 08:18:11 -07:00
|
|
|
for _, elt := range n.List.Slice() {
|
|
|
|
|
if elt.Op == OKEY {
|
|
|
|
|
elt = elt.Right
|
2016-10-27 02:02:30 -07:00
|
|
|
}
|
2017-03-14 08:18:11 -07:00
|
|
|
e.escassign(n, elt, e.stepAssignWhere(n, elt, "array literal element", n))
|
2015-05-15 12:19:07 -04:00
|
|
|
}
|
2016-06-19 07:20:28 -07:00
|
|
|
|
|
|
|
|
case OSLICELIT:
|
|
|
|
|
// Slice is not leaked until proven otherwise
|
|
|
|
|
e.track(n)
|
|
|
|
|
// Link values to slice
|
2017-03-14 08:18:11 -07:00
|
|
|
for _, elt := range n.List.Slice() {
|
|
|
|
|
if elt.Op == OKEY {
|
|
|
|
|
elt = elt.Right
|
2016-10-27 02:02:30 -07:00
|
|
|
}
|
2017-03-14 08:18:11 -07:00
|
|
|
e.escassign(n, elt, e.stepAssignWhere(n, elt, "slice literal element", n))
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Link values to struct.
|
|
|
|
|
case OSTRUCTLIT:
|
2017-03-14 08:18:11 -07:00
|
|
|
for _, elt := range n.List.Slice() {
|
|
|
|
|
e.escassignWhyWhere(n, elt.Left, "struct literal element", n)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
case OPTRLIT:
|
2015-05-27 07:31:56 -04:00
|
|
|
e.track(n)
|
2015-02-13 14:40:36 -05:00
|
|
|
|
|
|
|
|
// Link OSTRUCTLIT to OPTRLIT; if OPTRLIT escapes, OSTRUCTLIT elements do too.
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassignWhyWhere(n, n.Left, "pointer literal [assign]", n)
|
2015-02-13 14:40:36 -05:00
|
|
|
|
|
|
|
|
case OCALLPART:
|
2015-05-27 07:31:56 -04:00
|
|
|
e.track(n)
|
2015-02-13 14:40:36 -05:00
|
|
|
|
|
|
|
|
// Contents make it to memory, lose track.
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassignSinkWhy(n, n.Left, "call part")
|
2015-02-13 14:40:36 -05:00
|
|
|
|
|
|
|
|
case OMAPLIT:
|
2015-05-27 07:31:56 -04:00
|
|
|
e.track(n)
|
2015-02-13 14:40:36 -05:00
|
|
|
// Keys and values make it to memory, lose track.
|
2017-03-14 08:18:11 -07:00
|
|
|
for _, elt := range n.List.Slice() {
|
|
|
|
|
e.escassignSinkWhy(n, elt.Left, "map literal key")
|
|
|
|
|
e.escassignSinkWhy(n, elt.Right, "map literal value")
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
case OCLOSURE:
|
2016-05-27 00:56:19 -04:00
|
|
|
// Link addresses of captured variables to closure.
|
2016-02-26 17:03:58 -08:00
|
|
|
for _, v := range n.Func.Cvars.Slice() {
|
2015-10-22 09:51:12 +09:00
|
|
|
if v.Op == OXXX { // unnamed out argument; see dcl.go:/^funcargs
|
2015-02-13 14:40:36 -05:00
|
|
|
continue
|
|
|
|
|
}
|
2016-05-27 00:56:19 -04:00
|
|
|
a := v.Name.Defn
|
2017-02-27 19:56:38 +02:00
|
|
|
if !v.Name.Byval() {
|
2016-09-16 11:00:54 +10:00
|
|
|
a = nod(OADDR, a, nil)
|
2016-12-07 17:40:46 -08:00
|
|
|
a.Pos = v.Pos
|
2016-10-12 11:34:47 +09:00
|
|
|
e.nodeEscState(a).Loopdepth = e.loopdepth
|
cmd/compile: reduce use of **Node parameters
Escape analysis has a hard time with tree-like
structures (see #13493 and #14858).
This is unlikely to change.
As a result, when invoking a function that accepts
a **Node parameter, we usually allocate a *Node
on the heap. This happens a whole lot.
This CL changes functions from taking a **Node
to acting more like append: It both modifies
the input and returns a replacement for it.
Because of the cascading nature of escape analysis,
in order to get the benefits, I had to modify
almost all such functions. The remaining functions
are in racewalk and the backend. I would be happy
to update them as well in a separate CL.
This CL was created by manually updating the
function signatures and the directly impacted
bits of code. The callsites were then automatically
updated using a bespoke script:
https://gist.github.com/josharian/046b1be7aceae244de39
For ease of reviewing and future understanding,
this CL is also broken down into four CLs,
mailed separately, which show the manual
and the automated changes separately.
They are CLs 20990, 20991, 20992, and 20993.
Passes toolstash -cmp.
name old time/op new time/op delta
Template 335ms ± 5% 324ms ± 5% -3.35% (p=0.000 n=23+24)
Unicode 176ms ± 9% 165ms ± 6% -6.12% (p=0.000 n=23+24)
GoTypes 1.10s ± 4% 1.07s ± 2% -2.77% (p=0.000 n=24+24)
Compiler 5.31s ± 3% 5.15s ± 3% -2.95% (p=0.000 n=24+24)
MakeBash 41.6s ± 1% 41.7s ± 2% ~ (p=0.586 n=23+23)
name old alloc/op new alloc/op delta
Template 63.3MB ± 0% 62.4MB ± 0% -1.36% (p=0.000 n=25+23)
Unicode 42.4MB ± 0% 41.6MB ± 0% -1.99% (p=0.000 n=24+25)
GoTypes 220MB ± 0% 217MB ± 0% -1.11% (p=0.000 n=25+25)
Compiler 994MB ± 0% 973MB ± 0% -2.08% (p=0.000 n=24+25)
name old allocs/op new allocs/op delta
Template 681k ± 0% 574k ± 0% -15.71% (p=0.000 n=24+25)
Unicode 518k ± 0% 413k ± 0% -20.34% (p=0.000 n=25+24)
GoTypes 2.08M ± 0% 1.78M ± 0% -14.62% (p=0.000 n=25+25)
Compiler 9.26M ± 0% 7.64M ± 0% -17.48% (p=0.000 n=25+25)
name old text-bytes new text-bytes delta
HelloSize 578k ± 0% 578k ± 0% ~ (all samples are equal)
CmdGoSize 6.46M ± 0% 6.46M ± 0% ~ (all samples are equal)
name old data-bytes new data-bytes delta
HelloSize 128k ± 0% 128k ± 0% ~ (all samples are equal)
CmdGoSize 281k ± 0% 281k ± 0% ~ (all samples are equal)
name old exe-bytes new exe-bytes delta
HelloSize 921k ± 0% 921k ± 0% ~ (all samples are equal)
CmdGoSize 9.86M ± 0% 9.86M ± 0% ~ (all samples are equal)
Change-Id: I277d95bd56d51c166ef7f560647aeaa092f3f475
Reviewed-on: https://go-review.googlesource.com/20959
Reviewed-by: Dave Cheney <dave@cheney.net>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
2016-03-20 08:03:31 -07:00
|
|
|
a = typecheck(a, Erv)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassignWhyWhere(n, a, "captured by a closure", n)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
fallthrough
|
|
|
|
|
|
|
|
|
|
case OMAKECHAN,
|
|
|
|
|
OMAKEMAP,
|
|
|
|
|
OMAKESLICE,
|
|
|
|
|
ONEW,
|
|
|
|
|
OARRAYRUNESTR,
|
|
|
|
|
OARRAYBYTESTR,
|
|
|
|
|
OSTRARRAYRUNE,
|
|
|
|
|
OSTRARRAYBYTE,
|
|
|
|
|
ORUNESTR:
|
2015-05-27 07:31:56 -04:00
|
|
|
e.track(n)
|
2015-02-13 14:40:36 -05:00
|
|
|
|
|
|
|
|
case OADDSTR:
|
2015-05-27 07:31:56 -04:00
|
|
|
e.track(n)
|
|
|
|
|
// Arguments of OADDSTR do not escape.
|
2015-02-13 14:40:36 -05:00
|
|
|
|
|
|
|
|
case OADDR:
|
|
|
|
|
// current loop depth is an upper bound on actual loop depth
|
|
|
|
|
// of addressed value.
|
2015-05-27 07:31:56 -04:00
|
|
|
e.track(n)
|
2015-02-13 14:40:36 -05:00
|
|
|
|
|
|
|
|
// for &x, use loop depth of x if known.
|
|
|
|
|
// it should always be known, but if not, be conservative
|
|
|
|
|
// and keep the current loop depth.
|
|
|
|
|
if n.Left.Op == ONAME {
|
|
|
|
|
switch n.Left.Class {
|
|
|
|
|
case PAUTO:
|
2015-05-27 07:31:56 -04:00
|
|
|
nE := e.nodeEscState(n)
|
2015-05-26 23:42:41 -04:00
|
|
|
leftE := e.nodeEscState(n.Left)
|
2016-10-12 11:34:47 +09:00
|
|
|
if leftE.Loopdepth != 0 {
|
|
|
|
|
nE.Loopdepth = leftE.Loopdepth
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
2016-09-24 21:38:58 +02:00
|
|
|
// PPARAM is loop depth 1 always.
|
2015-02-13 14:40:36 -05:00
|
|
|
// PPARAMOUT is loop depth 0 for writes
|
|
|
|
|
// but considered loop depth 1 for address-of,
|
|
|
|
|
// so that writing the address of one result
|
|
|
|
|
// to another (or the same) result makes the
|
|
|
|
|
// first result move to the heap.
|
2015-04-01 09:38:44 -07:00
|
|
|
case PPARAM, PPARAMOUT:
|
2015-05-27 07:31:56 -04:00
|
|
|
nE := e.nodeEscState(n)
|
2016-10-12 11:34:47 +09:00
|
|
|
nE.Loopdepth = 1
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-03-02 17:34:42 -08:00
|
|
|
lineno = lno
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
2016-10-21 12:01:52 -04:00
|
|
|
// escassignWhyWhere bundles a common case of
|
|
|
|
|
// escassign(e, dst, src, e.stepAssignWhere(dst, src, reason, where))
|
|
|
|
|
func (e *EscState) escassignWhyWhere(dst, src *Node, reason string, where *Node) {
|
2016-02-29 10:43:18 -05:00
|
|
|
var step *EscStep
|
|
|
|
|
if Debug['m'] != 0 {
|
2016-10-21 12:01:52 -04:00
|
|
|
step = e.stepAssignWhere(dst, src, reason, where)
|
2016-02-29 10:43:18 -05:00
|
|
|
}
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escassign(dst, src, step)
|
2016-02-29 10:43:18 -05:00
|
|
|
}
|
|
|
|
|
|
2016-10-21 12:01:52 -04:00
|
|
|
// escassignSinkWhy bundles a common case of
|
2016-02-29 10:43:18 -05:00
|
|
|
// escassign(e, &e.theSink, src, e.stepAssign(nil, dst, src, reason))
|
2016-10-21 12:01:52 -04:00
|
|
|
func (e *EscState) escassignSinkWhy(dst, src *Node, reason string) {
|
2016-02-29 10:43:18 -05:00
|
|
|
var step *EscStep
|
|
|
|
|
if Debug['m'] != 0 {
|
|
|
|
|
step = e.stepAssign(nil, dst, src, reason)
|
|
|
|
|
}
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escassign(&e.theSink, src, step)
|
2016-02-29 10:43:18 -05:00
|
|
|
}
|
|
|
|
|
|
2016-10-21 12:01:52 -04:00
|
|
|
// escassignSinkWhyWhere is escassignSinkWhy but includes a call site
|
|
|
|
|
// for accurate location reporting.
|
|
|
|
|
func (e *EscState) escassignSinkWhyWhere(dst, src *Node, reason string, call *Node) {
|
|
|
|
|
var step *EscStep
|
|
|
|
|
if Debug['m'] != 0 {
|
|
|
|
|
step = e.stepAssignWhere(dst, src, reason, call)
|
|
|
|
|
}
|
|
|
|
|
e.escassign(&e.theSink, src, step)
|
|
|
|
|
}
|
|
|
|
|
|
2015-02-13 14:40:36 -05:00
|
|
|
// Assert that expr somehow gets assigned to dst, if non nil. for
|
|
|
|
|
// dst==nil, any name node expr still must be marked as being
|
|
|
|
|
// evaluated in curfn. For expr==nil, dst must still be examined for
|
|
|
|
|
// evaluations inside it (e.g *f(x) = y)
|
2016-10-12 11:34:47 +09:00
|
|
|
func (e *EscState) escassign(dst, src *Node, step *EscStep) {
|
2015-02-13 14:40:36 -05:00
|
|
|
if isblank(dst) || dst == nil || src == nil || src.Op == ONONAME || src.Op == OXXX {
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
2016-02-29 10:43:18 -05:00
|
|
|
if Debug['m'] > 2 {
|
2016-09-09 21:08:46 -07:00
|
|
|
fmt.Printf("%v:[%d] %v escassign: %S(%0j)[%v] = %S(%0j)[%v]\n",
|
2016-03-02 11:30:29 -08:00
|
|
|
linestr(lineno), e.loopdepth, funcSym(Curfn),
|
2016-08-31 15:22:36 -07:00
|
|
|
dst, dst, dst.Op,
|
|
|
|
|
src, src, src.Op)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
setlineno(dst)
|
|
|
|
|
|
2016-02-29 10:43:18 -05:00
|
|
|
originalDst := dst
|
|
|
|
|
dstwhy := "assigned"
|
|
|
|
|
|
2015-02-13 14:40:36 -05:00
|
|
|
// Analyze lhs of assignment.
|
2016-10-12 11:34:47 +09:00
|
|
|
// Replace dst with &e.theSink if we can't track it.
|
2015-02-13 14:40:36 -05:00
|
|
|
switch dst.Op {
|
|
|
|
|
default:
|
|
|
|
|
Dump("dst", dst)
|
2015-08-30 23:10:03 +02:00
|
|
|
Fatalf("escassign: unexpected dst")
|
2015-02-13 14:40:36 -05:00
|
|
|
|
|
|
|
|
case OARRAYLIT,
|
2016-06-19 07:20:28 -07:00
|
|
|
OSLICELIT,
|
2015-02-13 14:40:36 -05:00
|
|
|
OCLOSURE,
|
|
|
|
|
OCONV,
|
|
|
|
|
OCONVIFACE,
|
|
|
|
|
OCONVNOP,
|
|
|
|
|
OMAPLIT,
|
|
|
|
|
OSTRUCTLIT,
|
|
|
|
|
OPTRLIT,
|
2015-09-30 14:41:00 -04:00
|
|
|
ODDDARG,
|
2015-02-13 14:40:36 -05:00
|
|
|
OCALLPART:
|
|
|
|
|
|
|
|
|
|
case ONAME:
|
|
|
|
|
if dst.Class == PEXTERN {
|
2016-02-29 10:43:18 -05:00
|
|
|
dstwhy = "assigned to top level variable"
|
2015-02-13 14:40:36 -05:00
|
|
|
dst = &e.theSink
|
|
|
|
|
}
|
|
|
|
|
|
2016-02-13 22:39:16 -08:00
|
|
|
case ODOT: // treat "dst.x = src" as "dst = src"
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escassign(dst.Left, src, e.stepAssign(step, originalDst, src, "dot-equals"))
|
2015-02-13 14:40:36 -05:00
|
|
|
return
|
|
|
|
|
|
|
|
|
|
case OINDEX:
|
2016-03-30 14:45:47 -07:00
|
|
|
if dst.Left.Type.IsArray() {
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escassign(dst.Left, src, e.stepAssign(step, originalDst, src, "array-element-equals"))
|
2015-02-13 14:40:36 -05:00
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
2016-02-29 10:43:18 -05:00
|
|
|
dstwhy = "slice-element-equals"
|
|
|
|
|
dst = &e.theSink // lose track of dereference
|
|
|
|
|
|
|
|
|
|
case OIND:
|
|
|
|
|
dstwhy = "star-equals"
|
2015-02-13 14:40:36 -05:00
|
|
|
dst = &e.theSink // lose track of dereference
|
|
|
|
|
|
2016-02-29 10:43:18 -05:00
|
|
|
case ODOTPTR:
|
|
|
|
|
dstwhy = "star-dot-equals"
|
2015-02-13 14:40:36 -05:00
|
|
|
dst = &e.theSink // lose track of dereference
|
|
|
|
|
|
|
|
|
|
// lose track of key and value
|
|
|
|
|
case OINDEXMAP:
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escassign(&e.theSink, dst.Right, e.stepAssign(nil, originalDst, src, "key of map put"))
|
2016-02-29 10:43:18 -05:00
|
|
|
dstwhy = "value of map put"
|
2015-02-13 14:40:36 -05:00
|
|
|
dst = &e.theSink
|
|
|
|
|
}
|
|
|
|
|
|
2016-03-02 17:34:42 -08:00
|
|
|
lno := setlineno(src)
|
2015-02-13 14:40:36 -05:00
|
|
|
e.pdepth++
|
|
|
|
|
|
|
|
|
|
switch src.Op {
|
|
|
|
|
case OADDR, // dst = &x
|
|
|
|
|
OIND, // dst = *x
|
|
|
|
|
ODOTPTR, // dst = (*x).f
|
|
|
|
|
ONAME,
|
|
|
|
|
ODDDARG,
|
|
|
|
|
OPTRLIT,
|
|
|
|
|
OARRAYLIT,
|
2016-06-19 07:20:28 -07:00
|
|
|
OSLICELIT,
|
2015-02-13 14:40:36 -05:00
|
|
|
OMAPLIT,
|
|
|
|
|
OSTRUCTLIT,
|
|
|
|
|
OMAKECHAN,
|
|
|
|
|
OMAKEMAP,
|
|
|
|
|
OMAKESLICE,
|
|
|
|
|
OARRAYRUNESTR,
|
|
|
|
|
OARRAYBYTESTR,
|
|
|
|
|
OSTRARRAYRUNE,
|
|
|
|
|
OSTRARRAYBYTE,
|
|
|
|
|
OADDSTR,
|
|
|
|
|
ONEW,
|
|
|
|
|
OCALLPART,
|
2015-02-19 16:27:32 +03:00
|
|
|
ORUNESTR,
|
|
|
|
|
OCONVIFACE:
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escflows(dst, src, e.stepAssign(step, originalDst, src, dstwhy))
|
2015-02-13 14:40:36 -05:00
|
|
|
|
2015-04-06 18:17:20 +03:00
|
|
|
case OCLOSURE:
|
|
|
|
|
// OCLOSURE is lowered to OPTRLIT,
|
|
|
|
|
// insert OADDR to account for the additional indirection.
|
2016-09-16 11:00:54 +10:00
|
|
|
a := nod(OADDR, src, nil)
|
2016-12-07 17:40:46 -08:00
|
|
|
a.Pos = src.Pos
|
2016-10-12 11:34:47 +09:00
|
|
|
e.nodeEscState(a).Loopdepth = e.nodeEscState(src).Loopdepth
|
2017-03-19 09:51:22 +01:00
|
|
|
a.Type = typPtr(src.Type)
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escflows(dst, a, e.stepAssign(nil, originalDst, src, dstwhy))
|
2015-04-06 18:17:20 +03: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 16:36:15 -04:00
|
|
|
// Flowing multiple returns to a single dst happens when
|
2015-02-13 14:40:36 -05:00
|
|
|
// analyzing "go f(g())": here g() flows to sink (issue 4529).
|
2015-04-01 09:38:44 -07:00
|
|
|
case OCALLMETH, OCALLFUNC, OCALLINTER:
|
2016-10-12 11:34:47 +09:00
|
|
|
for _, n := range e.nodeEscState(src).Retval.Slice() {
|
|
|
|
|
e.escflows(dst, n, e.stepAssign(nil, originalDst, n, dstwhy))
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// A non-pointer escaping from a struct does not concern us.
|
|
|
|
|
case ODOT:
|
|
|
|
|
if src.Type != nil && !haspointers(src.Type) {
|
|
|
|
|
break
|
|
|
|
|
}
|
|
|
|
|
fallthrough
|
|
|
|
|
|
|
|
|
|
// Conversions, field access, slice all preserve the input value.
|
|
|
|
|
case OCONV,
|
|
|
|
|
OCONVNOP,
|
|
|
|
|
ODOTMETH,
|
|
|
|
|
// treat recv.meth as a value with recv in it, only happens in ODEFER and OPROC
|
|
|
|
|
// iface.method already leaks iface in esccall, no need to put in extra ODOTINTER edge here
|
|
|
|
|
OSLICE,
|
|
|
|
|
OSLICE3,
|
|
|
|
|
OSLICEARR,
|
|
|
|
|
OSLICE3ARR,
|
|
|
|
|
OSLICESTR:
|
2015-03-05 13:57:36 -05:00
|
|
|
// Conversions, field access, slice all preserve the input value.
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escassign(dst, src.Left, e.stepAssign(step, originalDst, src, dstwhy))
|
2015-02-13 14:40:36 -05:00
|
|
|
|
2016-07-13 12:29:39 -06:00
|
|
|
case ODOTTYPE,
|
|
|
|
|
ODOTTYPE2:
|
2016-02-13 22:39:16 -08:00
|
|
|
if src.Type != nil && !haspointers(src.Type) {
|
|
|
|
|
break
|
|
|
|
|
}
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escassign(dst, src.Left, e.stepAssign(step, originalDst, src, dstwhy))
|
2016-02-13 22:39:16 -08:00
|
|
|
|
2015-02-13 14:40:36 -05:00
|
|
|
case OAPPEND:
|
2015-03-05 13:57:36 -05:00
|
|
|
// Append returns first argument.
|
2015-05-15 12:19:07 -04:00
|
|
|
// Subsequent arguments are already leaked because they are operands to append.
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escassign(dst, src.List.First(), e.stepAssign(step, dst, src.List.First(), dstwhy))
|
2015-02-13 14:40:36 -05:00
|
|
|
|
|
|
|
|
case OINDEX:
|
2015-03-05 13:57:36 -05:00
|
|
|
// Index of array preserves input value.
|
2016-03-30 14:45:47 -07:00
|
|
|
if src.Left.Type.IsArray() {
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escassign(dst, src.Left, e.stepAssign(step, originalDst, src, dstwhy))
|
2015-05-15 12:19:07 -04:00
|
|
|
} else {
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escflows(dst, src, e.stepAssign(step, originalDst, src, dstwhy))
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
2016-09-24 21:38:58 +02:00
|
|
|
// Might be pointer arithmetic, in which case
|
2015-02-13 14:40:36 -05:00
|
|
|
// the operands flow into the result.
|
2016-03-01 23:21:55 +00:00
|
|
|
// TODO(rsc): Decide what the story is here. This is unsettling.
|
2015-02-13 14:40:36 -05:00
|
|
|
case OADD,
|
|
|
|
|
OSUB,
|
|
|
|
|
OOR,
|
|
|
|
|
OXOR,
|
|
|
|
|
OMUL,
|
|
|
|
|
ODIV,
|
|
|
|
|
OMOD,
|
|
|
|
|
OLSH,
|
|
|
|
|
ORSH,
|
|
|
|
|
OAND,
|
|
|
|
|
OANDNOT,
|
|
|
|
|
OPLUS,
|
|
|
|
|
OMINUS,
|
|
|
|
|
OCOM:
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escassign(dst, src.Left, e.stepAssign(step, originalDst, src, dstwhy))
|
2015-02-13 14:40:36 -05:00
|
|
|
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escassign(dst, src.Right, e.stepAssign(step, originalDst, src, dstwhy))
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
e.pdepth--
|
2016-03-02 17:34:42 -08:00
|
|
|
lineno = lno
|
2015-02-13 14:40:36 -05: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 16:36:15 -04:00
|
|
|
// Common case for escapes is 16 bits 000000000xxxEEEE
|
|
|
|
|
// where commonest cases for xxx encoding in-to-out pointer
|
|
|
|
|
// flow are 000, 001, 010, 011 and EEEE is computed Esc bits.
|
|
|
|
|
// Note width of xxx depends on value of constant
|
|
|
|
|
// bitsPerOutputInTag -- expect 2 or 3, so in practice the
|
2016-03-01 23:21:55 +00:00
|
|
|
// tag cache array is 64 or 128 long. Some entries will
|
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 16:36:15 -04:00
|
|
|
// never be populated.
|
|
|
|
|
var tags [1 << (bitsPerOutputInTag + EscReturnBits)]string
|
|
|
|
|
|
|
|
|
|
// mktag returns the string representation for an escape analysis tag.
|
2016-04-25 13:24:48 -07:00
|
|
|
func mktag(mask int) 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 16:36:15 -04:00
|
|
|
switch mask & EscMask {
|
|
|
|
|
case EscNone, EscReturn:
|
|
|
|
|
default:
|
2015-08-30 23:10:03 +02:00
|
|
|
Fatalf("escape mktag")
|
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 16:36:15 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if mask < len(tags) && tags[mask] != "" {
|
2016-04-25 13:24:48 -07:00
|
|
|
return tags[mask]
|
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 16:36:15 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
s := fmt.Sprintf("esc:0x%x", mask)
|
|
|
|
|
if mask < len(tags) {
|
|
|
|
|
tags[mask] = s
|
|
|
|
|
}
|
2016-04-25 13:24:48 -07:00
|
|
|
return s
|
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 16:36:15 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// parsetag decodes an escape analysis tag and returns the esc value.
|
2016-04-25 13:24:48 -07:00
|
|
|
func parsetag(note string) uint16 {
|
|
|
|
|
if !strings.HasPrefix(note, "esc:") {
|
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 16:36:15 -04:00
|
|
|
return EscUnknown
|
|
|
|
|
}
|
2016-04-25 13:24:48 -07:00
|
|
|
n, _ := strconv.ParseInt(note[4:], 0, 0)
|
2015-10-20 10:52:41 -07:00
|
|
|
em := uint16(n)
|
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 16:36:15 -04:00
|
|
|
if em == 0 {
|
|
|
|
|
return EscNone
|
|
|
|
|
}
|
|
|
|
|
return em
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// describeEscape returns a string describing the escape tag.
|
|
|
|
|
// The result is either one of {EscUnknown, EscNone, EscHeap} which all have no further annotation
|
|
|
|
|
// or a description of parameter flow, which takes the form of an optional "contentToHeap"
|
|
|
|
|
// indicating that the content of this parameter is leaked to the heap, followed by a sequence
|
|
|
|
|
// of level encodings separated by spaces, one for each parameter, where _ means no flow,
|
|
|
|
|
// = means direct flow, and N asterisks (*) encodes content (obtained by indirection) flow.
|
|
|
|
|
// e.g., "contentToHeap _ =" means that a parameter's content (one or more dereferences)
|
|
|
|
|
// escapes to the heap, the parameter does not leak to the first output, but does leak directly
|
|
|
|
|
// to the second output (and if there are more than two outputs, there is no flow to those.)
|
|
|
|
|
func describeEscape(em uint16) string {
|
|
|
|
|
var s string
|
|
|
|
|
if em&EscMask == EscUnknown {
|
|
|
|
|
s = "EscUnknown"
|
|
|
|
|
}
|
|
|
|
|
if em&EscMask == EscNone {
|
|
|
|
|
s = "EscNone"
|
|
|
|
|
}
|
|
|
|
|
if em&EscMask == EscHeap {
|
|
|
|
|
s = "EscHeap"
|
|
|
|
|
}
|
|
|
|
|
if em&EscMask == EscReturn {
|
|
|
|
|
s = "EscReturn"
|
|
|
|
|
}
|
|
|
|
|
if em&EscContentEscapes != 0 {
|
|
|
|
|
if s != "" {
|
|
|
|
|
s += " "
|
|
|
|
|
}
|
|
|
|
|
s += "contentToHeap"
|
|
|
|
|
}
|
|
|
|
|
for em >>= EscReturnBits; em != 0; em = em >> bitsPerOutputInTag {
|
|
|
|
|
// See encoding description above
|
|
|
|
|
if s != "" {
|
|
|
|
|
s += " "
|
|
|
|
|
}
|
|
|
|
|
switch embits := em & bitsMaskForTag; embits {
|
|
|
|
|
case 0:
|
|
|
|
|
s += "_"
|
|
|
|
|
case 1:
|
|
|
|
|
s += "="
|
|
|
|
|
default:
|
|
|
|
|
for i := uint16(0); i < embits-1; i++ {
|
|
|
|
|
s += "*"
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
return s
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// escassignfromtag models the input-to-output assignment flow of one of a function
|
|
|
|
|
// calls arguments, where the flow is encoded in "note".
|
2016-10-21 12:01:52 -04:00
|
|
|
func (e *EscState) escassignfromtag(note string, dsts Nodes, src, call *Node) uint16 {
|
2015-03-12 18:45:30 -04:00
|
|
|
em := parsetag(note)
|
2015-05-27 00:47:05 -04:00
|
|
|
if src.Op == OLITERAL {
|
|
|
|
|
return em
|
|
|
|
|
}
|
2015-02-13 14:40:36 -05:00
|
|
|
|
2016-02-29 10:43:18 -05:00
|
|
|
if Debug['m'] > 3 {
|
2016-09-09 21:08:46 -07:00
|
|
|
fmt.Printf("%v::assignfromtag:: src=%S, em=%s\n",
|
2016-08-31 15:22:36 -07:00
|
|
|
linestr(lineno), src, describeEscape(em))
|
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 16:36:15 -04:00
|
|
|
}
|
|
|
|
|
|
2015-02-13 14:40:36 -05:00
|
|
|
if em == EscUnknown {
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassignSinkWhyWhere(src, src, "passed to call[argument escapes]", call)
|
2015-02-13 14:40:36 -05:00
|
|
|
return em
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if em == EscNone {
|
|
|
|
|
return em
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// If content inside parameter (reached via indirection)
|
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 16:36:15 -04:00
|
|
|
// escapes to heap, mark as such.
|
2015-02-13 14:40:36 -05:00
|
|
|
if em&EscContentEscapes != 0 {
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassign(&e.theSink, e.addDereference(src), e.stepAssignWhere(src, src, "passed to call[argument content escapes]", call))
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
2015-02-23 16:07:24 -05:00
|
|
|
em0 := em
|
2016-03-09 12:39:36 -08:00
|
|
|
dstsi := 0
|
|
|
|
|
for em >>= EscReturnBits; em != 0 && dstsi < dsts.Len(); em = em >> bitsPerOutputInTag {
|
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 16:36:15 -04:00
|
|
|
// Prefer the lowest-level path to the reference (for escape purposes).
|
|
|
|
|
// Two-bit encoding (for example. 1, 3, and 4 bits are other options)
|
|
|
|
|
// 01 = 0-level
|
|
|
|
|
// 10 = 1-level, (content escapes),
|
|
|
|
|
// 11 = 2-level, (content of content escapes),
|
|
|
|
|
embits := em & bitsMaskForTag
|
|
|
|
|
if embits > 0 {
|
|
|
|
|
n := src
|
|
|
|
|
for i := uint16(0); i < embits-1; i++ {
|
2015-05-26 23:42:41 -04:00
|
|
|
n = e.addDereference(n) // encode level>0 as indirections
|
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 16:36:15 -04:00
|
|
|
}
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassign(dsts.Index(dstsi), n, e.stepAssignWhere(dsts.Index(dstsi), src, "passed-to-and-returned-from-call", call))
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
2016-03-09 12:39:36 -08:00
|
|
|
dstsi++
|
2015-02-13 14:40:36 -05: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 16:36:15 -04:00
|
|
|
// If there are too many outputs to fit in the tag,
|
|
|
|
|
// that is handled at the encoding end as EscHeap,
|
|
|
|
|
// so there is no need to check here.
|
2015-02-13 14:40:36 -05:00
|
|
|
|
2016-03-09 12:39:36 -08:00
|
|
|
if em != 0 && dstsi >= dsts.Len() {
|
2015-08-30 23:10:03 +02:00
|
|
|
Fatalf("corrupt esc tag %q or messed up escretval list\n", note)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
return em0
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-12 11:34:47 +09:00
|
|
|
func (e *EscState) escassignDereference(dst *Node, src *Node, step *EscStep) {
|
2015-06-03 14:16:01 -04:00
|
|
|
if src.Op == OLITERAL {
|
|
|
|
|
return
|
|
|
|
|
}
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escassign(dst, e.addDereference(src), step)
|
2015-06-03 14:16:01 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// addDereference constructs a suitable OIND note applied to src.
|
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 16:36:15 -04:00
|
|
|
// Because this is for purposes of escape accounting, not execution,
|
|
|
|
|
// some semantically dubious node combinations are (currently) possible.
|
2015-05-26 23:42:41 -04:00
|
|
|
func (e *EscState) addDereference(n *Node) *Node {
|
2016-09-16 11:00:54 +10:00
|
|
|
ind := nod(OIND, n, nil)
|
2016-10-12 11:34:47 +09:00
|
|
|
e.nodeEscState(ind).Loopdepth = e.nodeEscState(n).Loopdepth
|
2016-12-07 17:40:46 -08:00
|
|
|
ind.Pos = n.Pos
|
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 16:36:15 -04:00
|
|
|
t := n.Type
|
2016-04-01 13:36:24 -07:00
|
|
|
if t.IsKind(Tptr) {
|
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 16:36:15 -04:00
|
|
|
// This should model our own sloppy use of OIND to encode
|
|
|
|
|
// decreasing levels of indirection; i.e., "indirecting" an array
|
2016-03-01 23:21:55 +00:00
|
|
|
// might yield the type of an element. To be enhanced...
|
2016-03-30 10:57:47 -07:00
|
|
|
t = t.Elem()
|
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 16:36:15 -04:00
|
|
|
}
|
|
|
|
|
ind.Type = t
|
|
|
|
|
return ind
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// escNoteOutputParamFlow encodes maxEncodedLevel/.../1/0-level flow to the vargen'th parameter.
|
|
|
|
|
// Levels greater than maxEncodedLevel are replaced with maxEncodedLevel.
|
|
|
|
|
// If the encoding cannot describe the modified input level and output number, then EscHeap is returned.
|
|
|
|
|
func escNoteOutputParamFlow(e uint16, vargen int32, level Level) uint16 {
|
|
|
|
|
// Flow+level is encoded in two bits.
|
|
|
|
|
// 00 = not flow, xx = level+1 for 0 <= level <= maxEncodedLevel
|
|
|
|
|
// 16 bits for Esc allows 6x2bits or 4x3bits or 3x4bits if additional information would be useful.
|
|
|
|
|
if level.int() <= 0 && level.guaranteedDereference() > 0 {
|
|
|
|
|
return escMax(e|EscContentEscapes, EscNone) // At least one deref, thus only content.
|
|
|
|
|
}
|
|
|
|
|
if level.int() < 0 {
|
|
|
|
|
return EscHeap
|
|
|
|
|
}
|
|
|
|
|
if level.int() > maxEncodedLevel {
|
|
|
|
|
// Cannot encode larger values than maxEncodedLevel.
|
|
|
|
|
level = levelFrom(maxEncodedLevel)
|
|
|
|
|
}
|
|
|
|
|
encoded := uint16(level.int() + 1)
|
|
|
|
|
|
|
|
|
|
shift := uint(bitsPerOutputInTag*(vargen-1) + EscReturnBits)
|
|
|
|
|
old := (e >> shift) & bitsMaskForTag
|
|
|
|
|
if old == 0 || encoded != 0 && encoded < old {
|
|
|
|
|
old = encoded
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
encodedFlow := old << shift
|
|
|
|
|
if (encodedFlow>>shift)&bitsMaskForTag != old {
|
|
|
|
|
// Encoding failure defaults to heap.
|
|
|
|
|
return EscHeap
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return (e &^ (bitsMaskForTag << shift)) | encodedFlow
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-12 11:34:47 +09:00
|
|
|
func (e *EscState) initEscRetval(call *Node, fntype *Type) {
|
|
|
|
|
cE := e.nodeEscState(call)
|
|
|
|
|
cE.Retval.Set(nil) // Suspect this is not nil for indirect calls.
|
|
|
|
|
for i, f := range fntype.Results().Fields().Slice() {
|
2015-05-21 12:40:25 -04:00
|
|
|
buf := fmt.Sprintf(".out%d", i)
|
2017-03-24 15:57:12 -07:00
|
|
|
ret := newname(lookup(buf))
|
|
|
|
|
ret.SetAddable(false) // TODO(mdempsky): Seems suspicious.
|
2016-10-12 11:34:47 +09:00
|
|
|
ret.Type = f.Type
|
|
|
|
|
ret.Class = PAUTO
|
|
|
|
|
ret.Name.Curfn = Curfn
|
|
|
|
|
e.nodeEscState(ret).Loopdepth = e.loopdepth
|
2017-02-27 19:56:38 +02:00
|
|
|
ret.SetUsed(true)
|
2016-12-07 17:40:46 -08:00
|
|
|
ret.Pos = call.Pos
|
2016-10-12 11:34:47 +09:00
|
|
|
cE.Retval.Append(ret)
|
2015-05-21 12:40:25 -04:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2015-02-13 14:40:36 -05:00
|
|
|
// This is a bit messier than fortunate, pulled out of esc's big
|
2016-10-12 11:34:47 +09:00
|
|
|
// switch for clarity. We either have the paramnodes, which may be
|
2015-02-13 14:40:36 -05:00
|
|
|
// connected to other things through flows or we have the parameter type
|
|
|
|
|
// nodes, which may be marked "noescape". Navigating the ast is slightly
|
|
|
|
|
// different for methods vs plain functions and for imported vs
|
|
|
|
|
// this-package
|
2016-10-12 11:34:47 +09:00
|
|
|
func (e *EscState) esccall(call *Node, parent *Node) {
|
2015-02-13 14:40:36 -05:00
|
|
|
var fntype *Type
|
2015-05-21 12:40:25 -04:00
|
|
|
var indirect bool
|
2015-03-02 14:22:05 -05:00
|
|
|
var fn *Node
|
2016-10-12 11:34:47 +09:00
|
|
|
switch call.Op {
|
2015-02-13 14:40:36 -05:00
|
|
|
default:
|
2015-08-30 23:10:03 +02:00
|
|
|
Fatalf("esccall")
|
2015-02-13 14:40:36 -05:00
|
|
|
|
|
|
|
|
case OCALLFUNC:
|
2016-10-12 11:34:47 +09:00
|
|
|
fn = call.Left
|
2015-02-13 14:40:36 -05:00
|
|
|
fntype = fn.Type
|
2015-05-21 12:40:25 -04:00
|
|
|
indirect = fn.Op != ONAME || fn.Class != PFUNC
|
2015-02-13 14:40:36 -05:00
|
|
|
|
|
|
|
|
case OCALLMETH:
|
2016-10-12 11:34:47 +09:00
|
|
|
fn = call.Left.Sym.Def
|
2015-02-13 14:40:36 -05:00
|
|
|
if fn != nil {
|
|
|
|
|
fntype = fn.Type
|
|
|
|
|
} else {
|
2016-10-12 11:34:47 +09:00
|
|
|
fntype = call.Left.Type
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
case OCALLINTER:
|
2016-10-12 11:34:47 +09:00
|
|
|
fntype = call.Left.Type
|
2015-05-21 12:40:25 -04:00
|
|
|
indirect = true
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
2016-10-12 11:34:47 +09:00
|
|
|
argList := call.List
|
|
|
|
|
if argList.Len() == 1 {
|
|
|
|
|
arg := argList.First()
|
|
|
|
|
if arg.Type.IsFuncArgStruct() { // f(g())
|
|
|
|
|
argList = e.nodeEscState(arg).Retval
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-12 11:34:47 +09:00
|
|
|
args := argList.Slice()
|
|
|
|
|
|
2015-05-21 12:40:25 -04:00
|
|
|
if indirect {
|
|
|
|
|
// We know nothing!
|
|
|
|
|
// Leak all the parameters
|
2016-10-12 11:34:47 +09:00
|
|
|
for _, arg := range args {
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassignSinkWhy(call, arg, "parameter to indirect call")
|
2016-02-29 10:43:18 -05:00
|
|
|
if Debug['m'] > 3 {
|
2016-10-12 11:34:47 +09:00
|
|
|
fmt.Printf("%v::esccall:: indirect call <- %S, untracked\n", linestr(lineno), arg)
|
2015-05-21 12:40:25 -04:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
// Set up bogus outputs
|
2016-10-12 11:34:47 +09:00
|
|
|
e.initEscRetval(call, fntype)
|
2015-05-21 12:40:25 -04:00
|
|
|
// If there is a receiver, it also leaks to heap.
|
2016-10-12 11:34:47 +09:00
|
|
|
if call.Op != OCALLFUNC {
|
|
|
|
|
rf := fntype.Recv()
|
|
|
|
|
r := call.Left.Left
|
|
|
|
|
if haspointers(rf.Type) {
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassignSinkWhy(call, r, "receiver in indirect call")
|
2015-05-21 12:40:25 -04:00
|
|
|
}
|
2016-03-01 16:53:37 -05:00
|
|
|
} else { // indirect and OCALLFUNC = could be captured variables, too. (#14409)
|
2016-10-12 11:34:47 +09:00
|
|
|
rets := e.nodeEscState(call).Retval.Slice()
|
|
|
|
|
for _, ret := range rets {
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassignDereference(ret, fn, e.stepAssignWhere(ret, fn, "captured by called closure", call))
|
2016-03-01 16:53:37 -05:00
|
|
|
}
|
2015-05-21 12:40:25 -04:00
|
|
|
}
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-12 11:34:47 +09:00
|
|
|
cE := e.nodeEscState(call)
|
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 16:36:15 -04:00
|
|
|
if fn != nil && fn.Op == ONAME && fn.Class == PFUNC &&
|
2016-04-24 13:50:26 -07:00
|
|
|
fn.Name.Defn != nil && fn.Name.Defn.Nbody.Len() != 0 && fn.Name.Param.Ntype != nil && fn.Name.Defn.Esc < EscFuncTagged {
|
2016-02-29 10:43:18 -05:00
|
|
|
if Debug['m'] > 3 {
|
2016-10-12 11:34:47 +09:00
|
|
|
fmt.Printf("%v::esccall:: %S in recursive group\n", linestr(lineno), call)
|
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 16:36:15 -04:00
|
|
|
}
|
|
|
|
|
|
2016-03-01 23:21:55 +00:00
|
|
|
// function in same mutually recursive group. Incorporate into flow graph.
|
2016-10-12 11:34:47 +09:00
|
|
|
// print("esc local fn: %N\n", fn.Func.Ntype);
|
|
|
|
|
if fn.Name.Defn.Esc == EscFuncUnknown || cE.Retval.Len() != 0 {
|
2015-08-30 23:10:03 +02:00
|
|
|
Fatalf("graph inconsistency")
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
2016-03-27 19:44:06 -07:00
|
|
|
sawRcvr := false
|
2016-10-12 11:34:47 +09:00
|
|
|
for _, n := range fn.Name.Defn.Func.Dcl {
|
|
|
|
|
switch n.Class {
|
2016-03-27 19:44:06 -07:00
|
|
|
case PPARAM:
|
2016-10-12 11:34:47 +09:00
|
|
|
if call.Op != OCALLFUNC && !sawRcvr {
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassignWhyWhere(n, call.Left.Left, "call receiver", call)
|
2016-03-27 19:44:06 -07:00
|
|
|
sawRcvr = true
|
2016-03-29 07:30:17 -07:00
|
|
|
continue
|
2016-03-27 19:44:06 -07:00
|
|
|
}
|
2016-10-12 11:34:47 +09:00
|
|
|
if len(args) == 0 {
|
2016-03-29 07:30:17 -07:00
|
|
|
continue
|
2016-03-27 19:44:06 -07:00
|
|
|
}
|
2016-10-12 11:34:47 +09:00
|
|
|
arg := args[0]
|
2017-02-27 19:56:38 +02:00
|
|
|
if n.Isddd() && !call.Isddd() {
|
2016-03-27 19:44:06 -07:00
|
|
|
// Introduce ODDDARG node to represent ... allocation.
|
2016-10-12 11:34:47 +09:00
|
|
|
arg = nod(ODDDARG, nil, nil)
|
|
|
|
|
arr := typArray(n.Type.Elem(), int64(len(args)))
|
2017-03-19 09:51:22 +01:00
|
|
|
arg.Type = typPtr(arr) // make pointer so it will be tracked
|
2016-12-07 17:40:46 -08:00
|
|
|
arg.Pos = call.Pos
|
2016-10-12 11:34:47 +09:00
|
|
|
e.track(arg)
|
|
|
|
|
call.Right = arg
|
2016-03-27 19:44:06 -07:00
|
|
|
}
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassignWhyWhere(n, arg, "arg to recursive call", call) // TODO this message needs help.
|
2016-10-12 11:34:47 +09:00
|
|
|
if arg != args[0] {
|
2016-03-29 07:30:17 -07:00
|
|
|
// "..." arguments are untracked
|
2016-10-12 11:34:47 +09:00
|
|
|
for _, a := range args {
|
2016-03-29 07:30:17 -07:00
|
|
|
if Debug['m'] > 3 {
|
2016-10-12 11:34:47 +09:00
|
|
|
fmt.Printf("%v::esccall:: ... <- %S, untracked\n", linestr(lineno), a)
|
2016-03-29 07:30:17 -07:00
|
|
|
}
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassignSinkWhyWhere(arg, a, "... arg to recursive call", call)
|
2016-03-29 07:30:17 -07:00
|
|
|
}
|
|
|
|
|
// No more PPARAM processing, but keep
|
|
|
|
|
// going for PPARAMOUT.
|
2016-10-12 11:34:47 +09:00
|
|
|
args = nil
|
2016-03-29 07:30:17 -07:00
|
|
|
continue
|
2016-03-27 19:44:06 -07:00
|
|
|
}
|
2016-10-12 11:34:47 +09:00
|
|
|
args = args[1:]
|
2015-02-13 14:40:36 -05:00
|
|
|
|
2016-03-27 19:44:06 -07:00
|
|
|
case PPARAMOUT:
|
2016-10-12 11:34:47 +09:00
|
|
|
cE.Retval.Append(n)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
2016-03-01 23:21:55 +00:00
|
|
|
// Imported or completely analyzed function. Use the escape tags.
|
2016-10-12 11:34:47 +09:00
|
|
|
if cE.Retval.Len() != 0 {
|
|
|
|
|
Fatalf("esc already decorated call %+v\n", call)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
2016-02-29 10:43:18 -05:00
|
|
|
if Debug['m'] > 3 {
|
2016-10-12 11:34:47 +09:00
|
|
|
fmt.Printf("%v::esccall:: %S not recursive\n", linestr(lineno), call)
|
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 16:36:15 -04:00
|
|
|
}
|
|
|
|
|
|
2015-02-13 14:40:36 -05:00
|
|
|
// set up out list on this call node with dummy auto ONAMES in the current (calling) function.
|
2016-10-12 11:34:47 +09:00
|
|
|
e.initEscRetval(call, fntype)
|
2015-02-13 14:40:36 -05:00
|
|
|
|
2016-10-12 11:34:47 +09:00
|
|
|
// print("esc analyzed fn: %#N (%+T) returning (%+H)\n", fn, fntype, e.nodeEscState(call).Retval);
|
2015-02-13 14:40:36 -05:00
|
|
|
|
|
|
|
|
// Receiver.
|
2016-10-12 11:34:47 +09:00
|
|
|
if call.Op != OCALLFUNC {
|
|
|
|
|
rf := fntype.Recv()
|
|
|
|
|
r := call.Left.Left
|
|
|
|
|
if haspointers(rf.Type) {
|
2016-10-21 12:01:52 -04:00
|
|
|
e.escassignfromtag(rf.Note, cE.Retval, r, call)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-04-05 19:38:21 -07:00
|
|
|
for i, param := range fntype.Params().FieldSlice() {
|
|
|
|
|
note := param.Note
|
|
|
|
|
var arg *Node
|
2017-02-27 19:56:38 +02:00
|
|
|
if param.Isddd() && !call.Isddd() {
|
2017-04-05 19:38:21 -07:00
|
|
|
rest := args[i:]
|
|
|
|
|
if len(rest) == 0 {
|
|
|
|
|
break
|
|
|
|
|
}
|
|
|
|
|
|
2015-02-13 14:40:36 -05:00
|
|
|
// Introduce ODDDARG node to represent ... allocation.
|
2016-10-12 11:34:47 +09:00
|
|
|
arg = nod(ODDDARG, nil, nil)
|
2016-12-07 17:40:46 -08:00
|
|
|
arg.Pos = call.Pos
|
2017-04-05 19:38:21 -07:00
|
|
|
arr := typArray(param.Type.Elem(), int64(len(rest)))
|
2017-03-19 09:51:22 +01:00
|
|
|
arg.Type = typPtr(arr) // make pointer so it will be tracked
|
2016-10-12 11:34:47 +09:00
|
|
|
e.track(arg)
|
|
|
|
|
call.Right = arg
|
2015-02-13 14:40:36 -05:00
|
|
|
|
2017-04-05 19:38:21 -07:00
|
|
|
// Store arguments into slice for ... arg.
|
|
|
|
|
for _, a := range rest {
|
|
|
|
|
if Debug['m'] > 3 {
|
|
|
|
|
fmt.Printf("%v::esccall:: ... <- %S\n", linestr(lineno), a)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
2017-04-05 19:38:21 -07:00
|
|
|
if note == uintptrEscapesTag {
|
|
|
|
|
e.escassignSinkWhyWhere(arg, a, "arg to uintptrescapes ...", call)
|
|
|
|
|
} else {
|
|
|
|
|
e.escassignWhyWhere(arg, a, "arg to ...", call)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
}
|
2017-04-05 19:38:21 -07:00
|
|
|
} else {
|
|
|
|
|
arg = args[i]
|
|
|
|
|
if note == uintptrEscapesTag {
|
|
|
|
|
e.escassignSinkWhy(arg, arg, "escaping uintptr")
|
|
|
|
|
}
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
2017-04-05 19:38:21 -07:00
|
|
|
if haspointers(param.Type) && e.escassignfromtag(note, cE.Retval, arg, call)&EscMask == EscNone && parent.Op != ODEFER && parent.Op != OPROC {
|
|
|
|
|
a := arg
|
|
|
|
|
for a.Op == OCONVNOP {
|
|
|
|
|
a = a.Left
|
|
|
|
|
}
|
|
|
|
|
switch a.Op {
|
|
|
|
|
// The callee has already been analyzed, so its arguments have esc tags.
|
|
|
|
|
// The argument is marked as not escaping at all.
|
|
|
|
|
// Record that fact so that any temporary used for
|
|
|
|
|
// synthesizing this expression can be reclaimed when
|
|
|
|
|
// the function returns.
|
|
|
|
|
// This 'noescape' is even stronger than the usual esc == EscNone.
|
|
|
|
|
// arg.Esc == EscNone means that arg does not escape the current function.
|
|
|
|
|
// arg.SetNoescape(true) here means that arg does not escape this statement
|
|
|
|
|
// in the current function.
|
|
|
|
|
case OCALLPART, OCLOSURE, ODDDARG, OARRAYLIT, OSLICELIT, OPTRLIT, OSTRUCTLIT:
|
|
|
|
|
a.SetNoescape(true)
|
|
|
|
|
}
|
2016-06-28 14:19:27 -07:00
|
|
|
}
|
2015-02-13 14:40:36 -05: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 16:36:15 -04:00
|
|
|
// escflows records the link src->dst in dst, throwing out some quick wins,
|
|
|
|
|
// and also ensuring that dst is noted as a flow destination.
|
2016-10-12 11:34:47 +09:00
|
|
|
func (e *EscState) escflows(dst, src *Node, why *EscStep) {
|
2015-02-13 14:40:36 -05:00
|
|
|
if dst == nil || src == nil || dst == src {
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Don't bother building a graph for scalars.
|
2017-03-28 17:55:26 -04:00
|
|
|
if src.Type != nil && !haspointers(src.Type) && !isReflectHeaderDataField(src) {
|
|
|
|
|
if Debug['m'] > 3 {
|
|
|
|
|
fmt.Printf("%v::NOT flows:: %S <- %S\n", linestr(lineno), dst, src)
|
|
|
|
|
}
|
2015-02-13 14:40:36 -05:00
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
2016-02-29 10:43:18 -05:00
|
|
|
if Debug['m'] > 3 {
|
2016-09-09 21:08:46 -07:00
|
|
|
fmt.Printf("%v::flows:: %S <- %S\n", linestr(lineno), dst, src)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
2015-05-26 23:42:41 -04:00
|
|
|
dstE := e.nodeEscState(dst)
|
2016-10-12 11:34:47 +09:00
|
|
|
if len(dstE.Flowsrc) == 0 {
|
2016-03-03 17:38:14 -08:00
|
|
|
e.dsts = append(e.dsts, dst)
|
2015-02-13 14:40:36 -05:00
|
|
|
e.dstcount++
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
e.edgecount++
|
|
|
|
|
|
2016-02-29 10:43:18 -05:00
|
|
|
if why == nil {
|
2016-10-12 11:34:47 +09:00
|
|
|
dstE.Flowsrc = append(dstE.Flowsrc, EscStep{src: src})
|
2016-02-29 10:43:18 -05:00
|
|
|
} else {
|
|
|
|
|
starwhy := *why
|
|
|
|
|
starwhy.src = src // TODO: need to reconcile this w/ needs of explanations.
|
2016-10-12 11:34:47 +09:00
|
|
|
dstE.Flowsrc = append(dstE.Flowsrc, starwhy)
|
2016-02-29 10:43:18 -05:00
|
|
|
}
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Whenever we hit a reference node, the level goes up by one, and whenever
|
|
|
|
|
// we hit an OADDR, the level goes down by one. as long as we're on a level > 0
|
|
|
|
|
// finding an OADDR just means we're following the upstream of a dereference,
|
|
|
|
|
// so this address doesn't leak (yet).
|
|
|
|
|
// If level == 0, it means the /value/ of this node can reach the root of this flood.
|
2016-02-13 22:39:16 -08:00
|
|
|
// so if this node is an OADDR, its argument should be marked as escaping iff
|
2016-10-12 11:34:47 +09:00
|
|
|
// its currfn/e.loopdepth are different from the flood's root.
|
2016-02-13 22:39:16 -08:00
|
|
|
// Once an object has been moved to the heap, all of its upstream should be considered
|
2015-02-13 14:40:36 -05:00
|
|
|
// escaping to the global scope.
|
2016-10-12 11:34:47 +09:00
|
|
|
func (e *EscState) escflood(dst *Node) {
|
2015-02-13 14:40:36 -05:00
|
|
|
switch dst.Op {
|
2015-04-01 09:38:44 -07:00
|
|
|
case ONAME, OCLOSURE:
|
2015-02-13 14:40:36 -05:00
|
|
|
default:
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
2015-05-26 23:42:41 -04:00
|
|
|
dstE := e.nodeEscState(dst)
|
2016-02-29 10:43:18 -05:00
|
|
|
if Debug['m'] > 2 {
|
2016-10-12 11:34:47 +09:00
|
|
|
fmt.Printf("\nescflood:%d: dst %S scope:%v[%d]\n", e.walkgen, dst, e.curfnSym(dst), dstE.Loopdepth)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
2016-10-12 11:34:47 +09:00
|
|
|
for i := range dstE.Flowsrc {
|
2015-05-27 00:44:05 -04:00
|
|
|
e.walkgen++
|
2016-10-12 11:34:47 +09:00
|
|
|
s := &dstE.Flowsrc[i]
|
|
|
|
|
s.parent = nil
|
|
|
|
|
e.escwalk(levelFrom(0), dst, s.src, s)
|
2015-02-13 14:40:36 -05: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 16:36:15 -04:00
|
|
|
// funcOutputAndInput reports whether dst and src correspond to output and input parameters of the same function.
|
|
|
|
|
func funcOutputAndInput(dst, src *Node) bool {
|
|
|
|
|
// Note if dst is marked as escaping, then "returned" is too weak.
|
|
|
|
|
return dst.Op == ONAME && dst.Class == PPARAMOUT &&
|
2015-05-27 07:31:56 -04:00
|
|
|
src.Op == ONAME && src.Class == PPARAM && src.Name.Curfn == dst.Name.Curfn
|
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 16:36:15 -04:00
|
|
|
}
|
2015-02-13 14:40:36 -05:00
|
|
|
|
2016-02-29 10:43:18 -05:00
|
|
|
func (es *EscStep) describe(src *Node) {
|
|
|
|
|
if Debug['m'] < 2 {
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
step0 := es
|
|
|
|
|
for step := step0; step != nil && !step.busy; step = step.parent {
|
|
|
|
|
// TODO: We get cycles. Trigger is i = &i (where var i interface{})
|
|
|
|
|
step.busy = true
|
|
|
|
|
// The trail is a little odd because of how the
|
|
|
|
|
// graph is constructed. The link to the current
|
|
|
|
|
// Node is parent.src unless parent is nil in which
|
|
|
|
|
// case it is step.dst.
|
|
|
|
|
nextDest := step.parent
|
|
|
|
|
dst := step.dst
|
2016-10-21 12:01:52 -04:00
|
|
|
where := step.where
|
2016-02-29 10:43:18 -05:00
|
|
|
if nextDest != nil {
|
|
|
|
|
dst = nextDest.src
|
|
|
|
|
}
|
2016-10-21 12:01:52 -04:00
|
|
|
if where == nil {
|
|
|
|
|
where = dst
|
|
|
|
|
}
|
2016-12-07 17:40:46 -08:00
|
|
|
Warnl(src.Pos, "\tfrom %v (%s) at %s", dst, step.why, where.Line())
|
2016-02-29 10:43:18 -05:00
|
|
|
}
|
|
|
|
|
for step := step0; step != nil && step.busy; step = step.parent {
|
|
|
|
|
step.busy = false
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
cmd/compile: better modeling of escape across loop levels
Brief background on "why heap allocate". Things can be
forced to the heap for the following reasons:
1) address published, hence lifetime unknown.
2) size unknown/too large, cannot be stack allocated
3) multiplicity unknown/too large, cannot be stack allocated
4) reachable from heap (not necessarily published)
The bug here is a case of failing to enforce 4) when an
object Y was reachable from a heap allocation X forced
because of 3). It was found in the case of a closure
allocated within a loop (X) and assigned to a variable
outside the loop (multiplicity unknown) where the closure
also captured a map (Y) declared outside the loop (reachable
from heap). Note the variable declared outside the loop (Y)
is not published, has known size, and known multiplicity
(one). The only reason for heap allocation is that it was
reached from a heap allocated item (X), but because that was
not forced by publication, it has to be tracked by loop
level, but escape-loop level was not tracked and thus a bug
results.
The fix is that when a heap allocation is newly discovered,
use its looplevel as the minimum loop level for downstream
escape flooding.
Every attempt to generalize this bug to X-in-loop-
references-Y-outside loop succeeded, so the fix was aimed
to be general. Anywhere that loop level forces heap
allocation, the loop level is tracked. This is not yet
tested for all possible X and Y, but it is correctness-
conservative and because it caused only one trivial
regression in the escape tests, it is probably also
performance-conservative.
The new test checks the following:
1) in the map case, that if fn escapes, so does the map.
2) in the map case, if fn does not escape, neither does the map.
3) in the &x case, that if fn escapes, so does &x.
4) in the &x case, if fn does not escape, neither does &x.
Fixes #13799.
Change-Id: Ie280bef2bb86ec869c7c206789d0b68f080c3fdb
Reviewed-on: https://go-review.googlesource.com/18234
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2016-01-04 16:44:20 -05:00
|
|
|
const NOTALOOPDEPTH = -1
|
|
|
|
|
|
2016-10-12 11:34:47 +09:00
|
|
|
func (e *EscState) escwalk(level Level, dst *Node, src *Node, step *EscStep) {
|
|
|
|
|
e.escwalkBody(level, dst, src, step, NOTALOOPDEPTH)
|
cmd/compile: better modeling of escape across loop levels
Brief background on "why heap allocate". Things can be
forced to the heap for the following reasons:
1) address published, hence lifetime unknown.
2) size unknown/too large, cannot be stack allocated
3) multiplicity unknown/too large, cannot be stack allocated
4) reachable from heap (not necessarily published)
The bug here is a case of failing to enforce 4) when an
object Y was reachable from a heap allocation X forced
because of 3). It was found in the case of a closure
allocated within a loop (X) and assigned to a variable
outside the loop (multiplicity unknown) where the closure
also captured a map (Y) declared outside the loop (reachable
from heap). Note the variable declared outside the loop (Y)
is not published, has known size, and known multiplicity
(one). The only reason for heap allocation is that it was
reached from a heap allocated item (X), but because that was
not forced by publication, it has to be tracked by loop
level, but escape-loop level was not tracked and thus a bug
results.
The fix is that when a heap allocation is newly discovered,
use its looplevel as the minimum loop level for downstream
escape flooding.
Every attempt to generalize this bug to X-in-loop-
references-Y-outside loop succeeded, so the fix was aimed
to be general. Anywhere that loop level forces heap
allocation, the loop level is tracked. This is not yet
tested for all possible X and Y, but it is correctness-
conservative and because it caused only one trivial
regression in the escape tests, it is probably also
performance-conservative.
The new test checks the following:
1) in the map case, that if fn escapes, so does the map.
2) in the map case, if fn does not escape, neither does the map.
3) in the &x case, that if fn escapes, so does &x.
4) in the &x case, if fn does not escape, neither does &x.
Fixes #13799.
Change-Id: Ie280bef2bb86ec869c7c206789d0b68f080c3fdb
Reviewed-on: https://go-review.googlesource.com/18234
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2016-01-04 16:44:20 -05:00
|
|
|
}
|
|
|
|
|
|
2016-10-12 11:34:47 +09:00
|
|
|
func (e *EscState) escwalkBody(level Level, dst *Node, src *Node, step *EscStep, extraloopdepth int32) {
|
2015-05-27 00:47:05 -04:00
|
|
|
if src.Op == OLITERAL {
|
|
|
|
|
return
|
|
|
|
|
}
|
2015-05-26 23:42:41 -04:00
|
|
|
srcE := e.nodeEscState(src)
|
2015-05-27 00:44:05 -04:00
|
|
|
if srcE.Walkgen == e.walkgen {
|
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 16:36:15 -04:00
|
|
|
// Esclevels are vectors, do not compare as integers,
|
|
|
|
|
// and must use "min" of old and new to guarantee
|
|
|
|
|
// convergence.
|
2016-10-12 11:34:47 +09:00
|
|
|
level = level.min(srcE.Level)
|
|
|
|
|
if level == srcE.Level {
|
cmd/compile: better modeling of escape across loop levels
Brief background on "why heap allocate". Things can be
forced to the heap for the following reasons:
1) address published, hence lifetime unknown.
2) size unknown/too large, cannot be stack allocated
3) multiplicity unknown/too large, cannot be stack allocated
4) reachable from heap (not necessarily published)
The bug here is a case of failing to enforce 4) when an
object Y was reachable from a heap allocation X forced
because of 3). It was found in the case of a closure
allocated within a loop (X) and assigned to a variable
outside the loop (multiplicity unknown) where the closure
also captured a map (Y) declared outside the loop (reachable
from heap). Note the variable declared outside the loop (Y)
is not published, has known size, and known multiplicity
(one). The only reason for heap allocation is that it was
reached from a heap allocated item (X), but because that was
not forced by publication, it has to be tracked by loop
level, but escape-loop level was not tracked and thus a bug
results.
The fix is that when a heap allocation is newly discovered,
use its looplevel as the minimum loop level for downstream
escape flooding.
Every attempt to generalize this bug to X-in-loop-
references-Y-outside loop succeeded, so the fix was aimed
to be general. Anywhere that loop level forces heap
allocation, the loop level is tracked. This is not yet
tested for all possible X and Y, but it is correctness-
conservative and because it caused only one trivial
regression in the escape tests, it is probably also
performance-conservative.
The new test checks the following:
1) in the map case, that if fn escapes, so does the map.
2) in the map case, if fn does not escape, neither does the map.
3) in the &x case, that if fn escapes, so does &x.
4) in the &x case, if fn does not escape, neither does &x.
Fixes #13799.
Change-Id: Ie280bef2bb86ec869c7c206789d0b68f080c3fdb
Reviewed-on: https://go-review.googlesource.com/18234
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2016-01-04 16:44:20 -05:00
|
|
|
// Have we been here already with an extraloopdepth,
|
|
|
|
|
// or is the extraloopdepth provided no improvement on
|
|
|
|
|
// what's already been seen?
|
2016-10-12 11:34:47 +09:00
|
|
|
if srcE.Maxextraloopdepth >= extraloopdepth || srcE.Loopdepth >= extraloopdepth {
|
cmd/compile: better modeling of escape across loop levels
Brief background on "why heap allocate". Things can be
forced to the heap for the following reasons:
1) address published, hence lifetime unknown.
2) size unknown/too large, cannot be stack allocated
3) multiplicity unknown/too large, cannot be stack allocated
4) reachable from heap (not necessarily published)
The bug here is a case of failing to enforce 4) when an
object Y was reachable from a heap allocation X forced
because of 3). It was found in the case of a closure
allocated within a loop (X) and assigned to a variable
outside the loop (multiplicity unknown) where the closure
also captured a map (Y) declared outside the loop (reachable
from heap). Note the variable declared outside the loop (Y)
is not published, has known size, and known multiplicity
(one). The only reason for heap allocation is that it was
reached from a heap allocated item (X), but because that was
not forced by publication, it has to be tracked by loop
level, but escape-loop level was not tracked and thus a bug
results.
The fix is that when a heap allocation is newly discovered,
use its looplevel as the minimum loop level for downstream
escape flooding.
Every attempt to generalize this bug to X-in-loop-
references-Y-outside loop succeeded, so the fix was aimed
to be general. Anywhere that loop level forces heap
allocation, the loop level is tracked. This is not yet
tested for all possible X and Y, but it is correctness-
conservative and because it caused only one trivial
regression in the escape tests, it is probably also
performance-conservative.
The new test checks the following:
1) in the map case, that if fn escapes, so does the map.
2) in the map case, if fn does not escape, neither does the map.
3) in the &x case, that if fn escapes, so does &x.
4) in the &x case, if fn does not escape, neither does &x.
Fixes #13799.
Change-Id: Ie280bef2bb86ec869c7c206789d0b68f080c3fdb
Reviewed-on: https://go-review.googlesource.com/18234
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2016-01-04 16:44:20 -05:00
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
srcE.Maxextraloopdepth = extraloopdepth
|
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 16:36:15 -04:00
|
|
|
}
|
cmd/compile: better modeling of escape across loop levels
Brief background on "why heap allocate". Things can be
forced to the heap for the following reasons:
1) address published, hence lifetime unknown.
2) size unknown/too large, cannot be stack allocated
3) multiplicity unknown/too large, cannot be stack allocated
4) reachable from heap (not necessarily published)
The bug here is a case of failing to enforce 4) when an
object Y was reachable from a heap allocation X forced
because of 3). It was found in the case of a closure
allocated within a loop (X) and assigned to a variable
outside the loop (multiplicity unknown) where the closure
also captured a map (Y) declared outside the loop (reachable
from heap). Note the variable declared outside the loop (Y)
is not published, has known size, and known multiplicity
(one). The only reason for heap allocation is that it was
reached from a heap allocated item (X), but because that was
not forced by publication, it has to be tracked by loop
level, but escape-loop level was not tracked and thus a bug
results.
The fix is that when a heap allocation is newly discovered,
use its looplevel as the minimum loop level for downstream
escape flooding.
Every attempt to generalize this bug to X-in-loop-
references-Y-outside loop succeeded, so the fix was aimed
to be general. Anywhere that loop level forces heap
allocation, the loop level is tracked. This is not yet
tested for all possible X and Y, but it is correctness-
conservative and because it caused only one trivial
regression in the escape tests, it is probably also
performance-conservative.
The new test checks the following:
1) in the map case, that if fn escapes, so does the map.
2) in the map case, if fn does not escape, neither does the map.
3) in the &x case, that if fn escapes, so does &x.
4) in the &x case, if fn does not escape, neither does &x.
Fixes #13799.
Change-Id: Ie280bef2bb86ec869c7c206789d0b68f080c3fdb
Reviewed-on: https://go-review.googlesource.com/18234
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2016-01-04 16:44:20 -05:00
|
|
|
} else { // srcE.Walkgen < e.walkgen -- first time, reset this.
|
|
|
|
|
srcE.Maxextraloopdepth = NOTALOOPDEPTH
|
2015-02-13 14:40:36 -05: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 16:36:15 -04:00
|
|
|
|
2015-05-27 00:44:05 -04:00
|
|
|
srcE.Walkgen = e.walkgen
|
2016-10-12 11:34:47 +09:00
|
|
|
srcE.Level = level
|
|
|
|
|
modSrcLoopdepth := srcE.Loopdepth
|
cmd/compile: better modeling of escape across loop levels
Brief background on "why heap allocate". Things can be
forced to the heap for the following reasons:
1) address published, hence lifetime unknown.
2) size unknown/too large, cannot be stack allocated
3) multiplicity unknown/too large, cannot be stack allocated
4) reachable from heap (not necessarily published)
The bug here is a case of failing to enforce 4) when an
object Y was reachable from a heap allocation X forced
because of 3). It was found in the case of a closure
allocated within a loop (X) and assigned to a variable
outside the loop (multiplicity unknown) where the closure
also captured a map (Y) declared outside the loop (reachable
from heap). Note the variable declared outside the loop (Y)
is not published, has known size, and known multiplicity
(one). The only reason for heap allocation is that it was
reached from a heap allocated item (X), but because that was
not forced by publication, it has to be tracked by loop
level, but escape-loop level was not tracked and thus a bug
results.
The fix is that when a heap allocation is newly discovered,
use its looplevel as the minimum loop level for downstream
escape flooding.
Every attempt to generalize this bug to X-in-loop-
references-Y-outside loop succeeded, so the fix was aimed
to be general. Anywhere that loop level forces heap
allocation, the loop level is tracked. This is not yet
tested for all possible X and Y, but it is correctness-
conservative and because it caused only one trivial
regression in the escape tests, it is probably also
performance-conservative.
The new test checks the following:
1) in the map case, that if fn escapes, so does the map.
2) in the map case, if fn does not escape, neither does the map.
3) in the &x case, that if fn escapes, so does &x.
4) in the &x case, if fn does not escape, neither does &x.
Fixes #13799.
Change-Id: Ie280bef2bb86ec869c7c206789d0b68f080c3fdb
Reviewed-on: https://go-review.googlesource.com/18234
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2016-01-04 16:44:20 -05:00
|
|
|
|
|
|
|
|
if extraloopdepth > modSrcLoopdepth {
|
|
|
|
|
modSrcLoopdepth = extraloopdepth
|
|
|
|
|
}
|
2015-02-13 14:40:36 -05:00
|
|
|
|
2016-02-29 10:43:18 -05:00
|
|
|
if Debug['m'] > 2 {
|
2016-09-09 21:08:46 -07:00
|
|
|
fmt.Printf("escwalk: level:%d depth:%d %.*s op=%v %S(%0j) scope:%v[%d] extraloopdepth=%v\n",
|
2016-10-12 11:34:47 +09:00
|
|
|
level, e.pdepth, e.pdepth, "\t\t\t\t\t\t\t\t\t\t", src.Op, src, src, e.curfnSym(src), srcE.Loopdepth, extraloopdepth)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
e.pdepth++
|
|
|
|
|
|
|
|
|
|
// Input parameter flowing to output parameter?
|
2015-02-23 16:07:24 -05:00
|
|
|
var leaks bool
|
2016-02-29 10:43:18 -05:00
|
|
|
var osrcesc uint16 // used to prevent duplicate error messages
|
|
|
|
|
|
2015-05-26 23:42:41 -04:00
|
|
|
dstE := e.nodeEscState(dst)
|
2016-10-26 11:44:26 +09:00
|
|
|
if funcOutputAndInput(dst, src) && src.Esc&EscMask < EscHeap && dst.Esc != EscHeap {
|
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 16:36:15 -04:00
|
|
|
// This case handles:
|
|
|
|
|
// 1. return in
|
|
|
|
|
// 2. return &in
|
|
|
|
|
// 3. tmp := in; return &tmp
|
|
|
|
|
// 4. return *in
|
|
|
|
|
if Debug['m'] != 0 {
|
2016-02-29 10:43:18 -05:00
|
|
|
if Debug['m'] <= 2 {
|
2016-12-07 17:40:46 -08:00
|
|
|
Warnl(src.Pos, "leaking param: %S to result %v level=%v", src, dst.Sym, level.int())
|
2016-02-29 10:43:18 -05:00
|
|
|
step.describe(src)
|
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 16:36:15 -04:00
|
|
|
} else {
|
2016-12-07 17:40:46 -08:00
|
|
|
Warnl(src.Pos, "leaking param: %S to result %v level=%v", src, dst.Sym, level)
|
2015-02-13 14:40:36 -05: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 16:36:15 -04:00
|
|
|
if src.Esc&EscMask != EscReturn {
|
|
|
|
|
src.Esc = EscReturn | src.Esc&EscContentEscapes
|
|
|
|
|
}
|
2015-05-26 23:56:14 -04:00
|
|
|
src.Esc = escNoteOutputParamFlow(src.Esc, dst.Name.Vargen, level)
|
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 16:36:15 -04:00
|
|
|
goto recurse
|
2015-02-13 14:40:36 -05: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 16:36:15 -04:00
|
|
|
// If parameter content escapes to heap, set EscContentEscapes
|
|
|
|
|
// Note minor confusion around escape from pointer-to-struct vs escape from struct
|
|
|
|
|
if dst.Esc == EscHeap &&
|
2016-10-26 11:44:26 +09:00
|
|
|
src.Op == ONAME && src.Class == PPARAM && src.Esc&EscMask < EscHeap &&
|
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 16:36:15 -04:00
|
|
|
level.int() > 0 {
|
|
|
|
|
src.Esc = escMax(EscContentEscapes|src.Esc, EscNone)
|
|
|
|
|
if Debug['m'] != 0 {
|
2016-12-07 17:40:46 -08:00
|
|
|
Warnl(src.Pos, "mark escaped content: %S", src)
|
2016-02-29 10:43:18 -05:00
|
|
|
step.describe(src)
|
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 16:36:15 -04:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-12 11:34:47 +09:00
|
|
|
leaks = level.int() <= 0 && level.guaranteedDereference() <= 0 && dstE.Loopdepth < modSrcLoopdepth
|
2016-10-08 16:45:58 -04:00
|
|
|
leaks = leaks || level.int() <= 0 && dst.Esc&EscMask == EscHeap
|
2015-02-13 14:40:36 -05:00
|
|
|
|
2016-02-29 10:43:18 -05:00
|
|
|
osrcesc = src.Esc
|
2015-02-13 14:40:36 -05:00
|
|
|
switch src.Op {
|
|
|
|
|
case ONAME:
|
2016-10-26 11:44:26 +09:00
|
|
|
if src.Class == PPARAM && (leaks || dstE.Loopdepth < 0) && src.Esc&EscMask < EscHeap {
|
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 16:36:15 -04:00
|
|
|
if level.guaranteedDereference() > 0 {
|
|
|
|
|
src.Esc = escMax(EscContentEscapes|src.Esc, EscNone)
|
|
|
|
|
if Debug['m'] != 0 {
|
2016-02-29 10:43:18 -05:00
|
|
|
if Debug['m'] <= 2 {
|
|
|
|
|
if osrcesc != src.Esc {
|
2016-12-07 17:40:46 -08:00
|
|
|
Warnl(src.Pos, "leaking param content: %S", src)
|
2016-02-29 10:43:18 -05:00
|
|
|
step.describe(src)
|
|
|
|
|
}
|
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 16:36:15 -04:00
|
|
|
} else {
|
2016-12-07 17:40:46 -08:00
|
|
|
Warnl(src.Pos, "leaking param content: %S level=%v dst.eld=%v src.eld=%v dst=%S",
|
2016-10-12 11:34:47 +09:00
|
|
|
src, level, dstE.Loopdepth, modSrcLoopdepth, dst)
|
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 16:36:15 -04:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
} else {
|
2016-10-26 11:44:26 +09:00
|
|
|
src.Esc = EscHeap
|
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 16:36:15 -04:00
|
|
|
if Debug['m'] != 0 {
|
2016-02-29 10:43:18 -05:00
|
|
|
if Debug['m'] <= 2 {
|
2016-12-07 17:40:46 -08:00
|
|
|
Warnl(src.Pos, "leaking param: %S", src)
|
2016-02-29 10:43:18 -05:00
|
|
|
step.describe(src)
|
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 16:36:15 -04:00
|
|
|
} else {
|
2016-12-07 17:40:46 -08:00
|
|
|
Warnl(src.Pos, "leaking param: %S level=%v dst.eld=%v src.eld=%v dst=%S",
|
2016-10-12 11:34:47 +09:00
|
|
|
src, level, dstE.Loopdepth, modSrcLoopdepth, dst)
|
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 16:36:15 -04:00
|
|
|
}
|
|
|
|
|
}
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-05-25 10:29:50 -04:00
|
|
|
// Treat a captured closure variable as equivalent to the
|
2015-02-13 14:40:36 -05:00
|
|
|
// original variable.
|
2017-02-27 19:56:38 +02:00
|
|
|
if src.IsClosureVar() {
|
2015-02-17 22:13:49 -05:00
|
|
|
if leaks && Debug['m'] != 0 {
|
2016-12-07 17:40:46 -08:00
|
|
|
Warnl(src.Pos, "leaking closure reference %S", src)
|
2016-02-29 10:43:18 -05:00
|
|
|
step.describe(src)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escwalk(level, dst, src.Name.Defn, e.stepWalk(dst, src.Name.Defn, "closure-var", step))
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
2015-04-01 09:38:44 -07:00
|
|
|
case OPTRLIT, OADDR:
|
2016-02-29 10:43:18 -05:00
|
|
|
why := "pointer literal"
|
|
|
|
|
if src.Op == OADDR {
|
|
|
|
|
why = "address-of"
|
|
|
|
|
}
|
2015-02-17 22:13:49 -05:00
|
|
|
if leaks {
|
2015-02-13 14:40:36 -05:00
|
|
|
src.Esc = EscHeap
|
2016-02-29 10:43:18 -05:00
|
|
|
if Debug['m'] != 0 && osrcesc != src.Esc {
|
2015-04-06 18:17:20 +03:00
|
|
|
p := src
|
|
|
|
|
if p.Left.Op == OCLOSURE {
|
|
|
|
|
p = p.Left // merely to satisfy error messages in tests
|
|
|
|
|
}
|
2016-02-29 10:43:18 -05:00
|
|
|
if Debug['m'] > 2 {
|
2016-12-07 17:40:46 -08:00
|
|
|
Warnl(src.Pos, "%S escapes to heap, level=%v, dst=%v dst.eld=%v, src.eld=%v",
|
2016-10-12 11:34:47 +09:00
|
|
|
p, level, dst, dstE.Loopdepth, modSrcLoopdepth)
|
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 16:36:15 -04:00
|
|
|
} else {
|
2016-12-07 17:40:46 -08:00
|
|
|
Warnl(src.Pos, "%S escapes to heap", p)
|
2016-02-29 10:43:18 -05:00
|
|
|
step.describe(src)
|
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 16:36:15 -04:00
|
|
|
}
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
cmd/compile: fix liveness computation for heap-escaped parameters
The liveness computation of parameters generally was never
correct, but forcing all parameters to be live throughout the
function covered up that problem. The new SSA back end is
too clever: even though it currently keeps the parameter values live
throughout the function, it may find optimizations that mean
the current values are not written back to the original parameter
stack slots immediately or ever (for example if a parameter is set
to nil, SSA constant propagation may replace all later uses of the
parameter with a constant nil, eliminating the need to write the nil
value back to the stack slot), so the liveness code must now
track the actual operations on the stack slots, exposing these
problems.
One small problem in the handling of arguments is that nodarg
can return ONAME PPARAM nodes with adjusted offsets, so that
there are actually multiple *Node pointers for the same parameter
in the instruction stream. This might be possible to correct, but
not in this CL. For now, we fix this by using n.Orig instead of n
when considering PPARAM and PPARAMOUT nodes.
The major problem in the handling of arguments is general
confusion in the liveness code about the meaning of PPARAM|PHEAP
and PPARAMOUT|PHEAP nodes, especially as contrasted with PAUTO|PHEAP.
The difference between these two is that when a local variable "moves"
to the heap, it's really just allocated there to start with; in contrast,
when an argument moves to the heap, the actual data has to be copied
there from the stack at the beginning of the function, and when a
result "moves" to the heap the value in the heap has to be copied
back to the stack when the function returns
This general confusion is also present in the SSA back end.
The PHEAP bit worked decently when I first introduced it 7 years ago (!)
in 391425ae. The back end did nothing sophisticated, and in particular
there was no analysis at all: no escape analysis, no liveness analysis,
and certainly no SSA back end. But the complications caused in the
various downstream consumers suggest that this should be a detail
kept mainly in the front end.
This CL therefore eliminates both the PHEAP bit and even the idea of
"heap variables" from the back ends.
First, it replaces the PPARAM|PHEAP, PPARAMOUT|PHEAP, and PAUTO|PHEAP
variable classes with the single PAUTOHEAP, a pseudo-class indicating
a variable maintained on the heap and available by indirecting a
local variable kept on the stack (a plain PAUTO).
Second, walkexpr replaces all references to PAUTOHEAP variables
with indirections of the corresponding PAUTO variable.
The back ends and the liveness code now just see plain indirected
variables. This may actually produce better code, but the real goal
here is to eliminate these little-used and somewhat suspect code
paths in the back end analyses.
The OPARAM node type goes away too.
A followup CL will do the same to PPARAMREF. I'm not sure that
the back ends (SSA in particular) are handling those right either,
and with the framework established in this CL that change is trivial
and the result clearly more correct.
Fixes #15747.
Change-Id: I2770b1ce3cbc93981bfc7166be66a9da12013d74
Reviewed-on: https://go-review.googlesource.com/23393
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-05-25 01:33:24 -04:00
|
|
|
addrescapes(src.Left)
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escwalkBody(level.dec(), dst, src.Left, e.stepWalk(dst, src.Left, why, step), modSrcLoopdepth)
|
cmd/compile: better modeling of escape across loop levels
Brief background on "why heap allocate". Things can be
forced to the heap for the following reasons:
1) address published, hence lifetime unknown.
2) size unknown/too large, cannot be stack allocated
3) multiplicity unknown/too large, cannot be stack allocated
4) reachable from heap (not necessarily published)
The bug here is a case of failing to enforce 4) when an
object Y was reachable from a heap allocation X forced
because of 3). It was found in the case of a closure
allocated within a loop (X) and assigned to a variable
outside the loop (multiplicity unknown) where the closure
also captured a map (Y) declared outside the loop (reachable
from heap). Note the variable declared outside the loop (Y)
is not published, has known size, and known multiplicity
(one). The only reason for heap allocation is that it was
reached from a heap allocated item (X), but because that was
not forced by publication, it has to be tracked by loop
level, but escape-loop level was not tracked and thus a bug
results.
The fix is that when a heap allocation is newly discovered,
use its looplevel as the minimum loop level for downstream
escape flooding.
Every attempt to generalize this bug to X-in-loop-
references-Y-outside loop succeeded, so the fix was aimed
to be general. Anywhere that loop level forces heap
allocation, the loop level is tracked. This is not yet
tested for all possible X and Y, but it is correctness-
conservative and because it caused only one trivial
regression in the escape tests, it is probably also
performance-conservative.
The new test checks the following:
1) in the map case, that if fn escapes, so does the map.
2) in the map case, if fn does not escape, neither does the map.
3) in the &x case, that if fn escapes, so does &x.
4) in the &x case, if fn does not escape, neither does &x.
Fixes #13799.
Change-Id: Ie280bef2bb86ec869c7c206789d0b68f080c3fdb
Reviewed-on: https://go-review.googlesource.com/18234
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2016-01-04 16:44:20 -05:00
|
|
|
extraloopdepth = modSrcLoopdepth // passes to recursive case, seems likely a no-op
|
|
|
|
|
} else {
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escwalk(level.dec(), dst, src.Left, e.stepWalk(dst, src.Left, why, step))
|
2015-02-13 14:40:36 -05: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 16:36:15 -04:00
|
|
|
case OAPPEND:
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escwalk(level, dst, src.List.First(), e.stepWalk(dst, src.List.First(), "append-first-arg", step))
|
2015-02-13 14:40:36 -05:00
|
|
|
|
2015-09-30 14:41:00 -04:00
|
|
|
case ODDDARG:
|
|
|
|
|
if leaks {
|
|
|
|
|
src.Esc = EscHeap
|
2016-02-29 10:43:18 -05:00
|
|
|
if Debug['m'] != 0 && osrcesc != src.Esc {
|
2016-12-07 17:40:46 -08:00
|
|
|
Warnl(src.Pos, "%S escapes to heap", src)
|
2016-02-29 10:43:18 -05:00
|
|
|
step.describe(src)
|
2015-09-30 14:41:00 -04:00
|
|
|
}
|
cmd/compile: better modeling of escape across loop levels
Brief background on "why heap allocate". Things can be
forced to the heap for the following reasons:
1) address published, hence lifetime unknown.
2) size unknown/too large, cannot be stack allocated
3) multiplicity unknown/too large, cannot be stack allocated
4) reachable from heap (not necessarily published)
The bug here is a case of failing to enforce 4) when an
object Y was reachable from a heap allocation X forced
because of 3). It was found in the case of a closure
allocated within a loop (X) and assigned to a variable
outside the loop (multiplicity unknown) where the closure
also captured a map (Y) declared outside the loop (reachable
from heap). Note the variable declared outside the loop (Y)
is not published, has known size, and known multiplicity
(one). The only reason for heap allocation is that it was
reached from a heap allocated item (X), but because that was
not forced by publication, it has to be tracked by loop
level, but escape-loop level was not tracked and thus a bug
results.
The fix is that when a heap allocation is newly discovered,
use its looplevel as the minimum loop level for downstream
escape flooding.
Every attempt to generalize this bug to X-in-loop-
references-Y-outside loop succeeded, so the fix was aimed
to be general. Anywhere that loop level forces heap
allocation, the loop level is tracked. This is not yet
tested for all possible X and Y, but it is correctness-
conservative and because it caused only one trivial
regression in the escape tests, it is probably also
performance-conservative.
The new test checks the following:
1) in the map case, that if fn escapes, so does the map.
2) in the map case, if fn does not escape, neither does the map.
3) in the &x case, that if fn escapes, so does &x.
4) in the &x case, if fn does not escape, neither does &x.
Fixes #13799.
Change-Id: Ie280bef2bb86ec869c7c206789d0b68f080c3fdb
Reviewed-on: https://go-review.googlesource.com/18234
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2016-01-04 16:44:20 -05:00
|
|
|
extraloopdepth = modSrcLoopdepth
|
2015-09-30 14:41:00 -04:00
|
|
|
}
|
|
|
|
|
// similar to a slice arraylit and its args.
|
|
|
|
|
level = level.dec()
|
|
|
|
|
|
2016-06-19 07:20:28 -07:00
|
|
|
case OSLICELIT:
|
2017-03-14 08:18:11 -07:00
|
|
|
for _, elt := range src.List.Slice() {
|
|
|
|
|
if elt.Op == OKEY {
|
|
|
|
|
elt = elt.Right
|
2016-10-27 02:02:30 -07:00
|
|
|
}
|
2017-03-14 08:18:11 -07:00
|
|
|
e.escwalk(level.dec(), dst, elt, e.stepWalk(dst, elt, "slice-literal-element", step))
|
2015-05-15 12:19:07 -04:00
|
|
|
}
|
|
|
|
|
|
2015-02-13 14:40:36 -05:00
|
|
|
fallthrough
|
|
|
|
|
|
2015-09-30 14:41:00 -04:00
|
|
|
case OMAKECHAN,
|
2015-02-13 14:40:36 -05:00
|
|
|
OMAKEMAP,
|
|
|
|
|
OMAKESLICE,
|
|
|
|
|
OARRAYRUNESTR,
|
|
|
|
|
OARRAYBYTESTR,
|
|
|
|
|
OSTRARRAYRUNE,
|
|
|
|
|
OSTRARRAYBYTE,
|
|
|
|
|
OADDSTR,
|
|
|
|
|
OMAPLIT,
|
|
|
|
|
ONEW,
|
|
|
|
|
OCLOSURE,
|
|
|
|
|
OCALLPART,
|
2015-02-19 16:27:32 +03:00
|
|
|
ORUNESTR,
|
|
|
|
|
OCONVIFACE:
|
2015-02-17 22:13:49 -05:00
|
|
|
if leaks {
|
2015-02-13 14:40:36 -05:00
|
|
|
src.Esc = EscHeap
|
2016-02-29 10:43:18 -05:00
|
|
|
if Debug['m'] != 0 && osrcesc != src.Esc {
|
2016-12-07 17:40:46 -08:00
|
|
|
Warnl(src.Pos, "%S escapes to heap", src)
|
2016-02-29 10:43:18 -05:00
|
|
|
step.describe(src)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
cmd/compile: better modeling of escape across loop levels
Brief background on "why heap allocate". Things can be
forced to the heap for the following reasons:
1) address published, hence lifetime unknown.
2) size unknown/too large, cannot be stack allocated
3) multiplicity unknown/too large, cannot be stack allocated
4) reachable from heap (not necessarily published)
The bug here is a case of failing to enforce 4) when an
object Y was reachable from a heap allocation X forced
because of 3). It was found in the case of a closure
allocated within a loop (X) and assigned to a variable
outside the loop (multiplicity unknown) where the closure
also captured a map (Y) declared outside the loop (reachable
from heap). Note the variable declared outside the loop (Y)
is not published, has known size, and known multiplicity
(one). The only reason for heap allocation is that it was
reached from a heap allocated item (X), but because that was
not forced by publication, it has to be tracked by loop
level, but escape-loop level was not tracked and thus a bug
results.
The fix is that when a heap allocation is newly discovered,
use its looplevel as the minimum loop level for downstream
escape flooding.
Every attempt to generalize this bug to X-in-loop-
references-Y-outside loop succeeded, so the fix was aimed
to be general. Anywhere that loop level forces heap
allocation, the loop level is tracked. This is not yet
tested for all possible X and Y, but it is correctness-
conservative and because it caused only one trivial
regression in the escape tests, it is probably also
performance-conservative.
The new test checks the following:
1) in the map case, that if fn escapes, so does the map.
2) in the map case, if fn does not escape, neither does the map.
3) in the &x case, that if fn escapes, so does &x.
4) in the &x case, if fn does not escape, neither does &x.
Fixes #13799.
Change-Id: Ie280bef2bb86ec869c7c206789d0b68f080c3fdb
Reviewed-on: https://go-review.googlesource.com/18234
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
2016-01-04 16:44:20 -05:00
|
|
|
extraloopdepth = modSrcLoopdepth
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
case ODOT,
|
2016-02-29 10:43:18 -05:00
|
|
|
ODOTTYPE:
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escwalk(level, dst, src.Left, e.stepWalk(dst, src.Left, "dot", step))
|
2016-02-29 10:43:18 -05:00
|
|
|
|
|
|
|
|
case
|
2015-02-13 14:40:36 -05:00
|
|
|
OSLICE,
|
|
|
|
|
OSLICEARR,
|
|
|
|
|
OSLICE3,
|
|
|
|
|
OSLICE3ARR,
|
|
|
|
|
OSLICESTR:
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escwalk(level, dst, src.Left, e.stepWalk(dst, src.Left, "slice", step))
|
2015-02-13 14:40:36 -05:00
|
|
|
|
|
|
|
|
case OINDEX:
|
2016-03-30 14:45:47 -07:00
|
|
|
if src.Left.Type.IsArray() {
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escwalk(level, dst, src.Left, e.stepWalk(dst, src.Left, "fixed-array-index-of", step))
|
2015-02-13 14:40:36 -05:00
|
|
|
break
|
|
|
|
|
}
|
|
|
|
|
fallthrough
|
|
|
|
|
|
2016-02-29 10:43:18 -05:00
|
|
|
case ODOTPTR:
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escwalk(level.inc(), dst, src.Left, e.stepWalk(dst, src.Left, "dot of pointer", step))
|
2016-02-29 10:43:18 -05:00
|
|
|
case OINDEXMAP:
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escwalk(level.inc(), dst, src.Left, e.stepWalk(dst, src.Left, "map index", step))
|
2016-02-29 10:43:18 -05:00
|
|
|
case OIND:
|
2016-10-12 11:34:47 +09:00
|
|
|
e.escwalk(level.inc(), dst, src.Left, e.stepWalk(dst, src.Left, "indirection", step))
|
2015-02-13 14:40:36 -05: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 16:36:15 -04:00
|
|
|
// In this case a link went directly to a call, but should really go
|
|
|
|
|
// to the dummy .outN outputs that were created for the call that
|
|
|
|
|
// themselves link to the inputs with levels adjusted.
|
|
|
|
|
// See e.g. #10466
|
|
|
|
|
// This can only happen with functions returning a single result.
|
|
|
|
|
case OCALLMETH, OCALLFUNC, OCALLINTER:
|
2016-10-12 11:34:47 +09:00
|
|
|
if srcE.Retval.Len() != 0 {
|
2016-02-29 10:43:18 -05:00
|
|
|
if Debug['m'] > 2 {
|
2016-09-09 21:08:46 -07:00
|
|
|
fmt.Printf("%v:[%d] dst %S escwalk replace src: %S with %S\n",
|
2016-03-02 11:30:29 -08:00
|
|
|
linestr(lineno), e.loopdepth,
|
2016-10-12 11:34:47 +09:00
|
|
|
dst, src, srcE.Retval.First())
|
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 16:36:15 -04:00
|
|
|
}
|
2016-10-12 11:34:47 +09:00
|
|
|
src = srcE.Retval.First()
|
2015-05-26 23:42:41 -04:00
|
|
|
srcE = e.nodeEscState(src)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
recurse:
|
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 16:36:15 -04:00
|
|
|
level = level.copy()
|
2016-10-12 11:34:47 +09:00
|
|
|
|
|
|
|
|
for i := range srcE.Flowsrc {
|
|
|
|
|
s := &srcE.Flowsrc[i]
|
|
|
|
|
s.parent = step
|
|
|
|
|
e.escwalkBody(level, dst, s.src, s, extraloopdepth)
|
|
|
|
|
s.parent = nil
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
e.pdepth--
|
|
|
|
|
}
|
|
|
|
|
|
cmd/compile: recognize Syscall-like functions for liveness analysis
Consider this code:
func f(*int)
func g() {
p := new(int)
f(p)
}
where f is an assembly function.
In general liveness analysis assumes that during the call to f, p is dead
in this frame. If f has retained p, p will be found alive in f's frame and keep
the new(int) from being garbage collected. This is all correct and works.
We use the Go func declaration for f to give the assembly function
liveness information (the arguments are assumed live for the entire call).
Now consider this code:
func h1() {
p := new(int)
syscall.Syscall(1, 2, 3, uintptr(unsafe.Pointer(p)))
}
Here syscall.Syscall is taking the place of f, but because its arguments
are uintptr, the liveness analysis and the garbage collector ignore them.
Since p is no longer live in h once the call starts, if the garbage collector
scans the stack while the system call is blocked, it will find no reference
to the new(int) and reclaim it. If the kernel is going to write to *p once
the call finishes, reclaiming the memory is a mistake.
We can't change the arguments or the liveness information for
syscall.Syscall itself, both for compatibility and because sometimes the
arguments really are integers, and the garbage collector will get quite upset
if it finds an integer where it expects a pointer. The problem is that
these arguments are fundamentally untyped.
The solution we have taken in the syscall package's wrappers in past
releases is to insert a call to a dummy function named "use", to make
it look like the argument is live during the call to syscall.Syscall:
func h2() {
p := new(int)
syscall.Syscall(1, 2, 3, uintptr(unsafe.Pointer(p)))
use(unsafe.Pointer(p))
}
Keeping p alive during the call means that if the garbage collector
scans the stack during the system call now, it will find the reference to p.
Unfortunately, this approach is not available to users outside syscall,
because 'use' is unexported, and people also have to realize they need
to use it and do so. There is much existing code using syscall.Syscall
without a 'use'-like function. That code will fail very occasionally in
mysterious ways (see #13372).
This CL fixes all that existing code by making the compiler do the right
thing automatically, without any code modifications. That is, it takes h1
above, which is incorrect code today, and makes it correct code.
Specifically, if the compiler sees a foreign func definition (one
without a body) that has uintptr arguments, it marks those arguments
as "unsafe uintptrs". If it later sees the function being called
with uintptr(unsafe.Pointer(x)) as an argument, it arranges to mark x
as having escaped, and it makes sure to hold x in a live temporary
variable until the call returns, so that the garbage collector cannot
reclaim whatever heap memory x points to.
For now I am leaving the explicit calls to use in package syscall,
but they can be removed early in a future cycle (likely Go 1.7).
The rule has no effect on escape analysis, only on liveness analysis.
Fixes #13372.
Change-Id: I2addb83f70d08db08c64d394f9d06ff0a063c500
Reviewed-on: https://go-review.googlesource.com/18584
Reviewed-by: Ian Lance Taylor <iant@golang.org>
2016-01-13 00:46:28 -05:00
|
|
|
// This special tag is applied to uintptr variables
|
|
|
|
|
// that we believe may hold unsafe.Pointers for
|
|
|
|
|
// calls into assembly functions.
|
|
|
|
|
// It is logically a constant, but using a var
|
|
|
|
|
// lets us take the address below to get a *string.
|
|
|
|
|
var unsafeUintptrTag = "unsafe-uintptr"
|
|
|
|
|
|
2016-06-28 14:19:27 -07:00
|
|
|
// This special tag is applied to uintptr parameters of functions
|
|
|
|
|
// marked go:uintptrescapes.
|
|
|
|
|
const uintptrEscapesTag = "uintptr-escapes"
|
|
|
|
|
|
2016-10-12 11:34:47 +09:00
|
|
|
func (e *EscState) esctag(fn *Node) {
|
|
|
|
|
fn.Esc = EscFuncTagged
|
2015-02-13 14:40:36 -05:00
|
|
|
|
2016-06-28 14:19:27 -07:00
|
|
|
name := func(s *Sym, narg int) string {
|
|
|
|
|
if s != nil {
|
|
|
|
|
return s.Name
|
|
|
|
|
}
|
|
|
|
|
return fmt.Sprintf("arg#%d", narg)
|
|
|
|
|
}
|
|
|
|
|
|
2015-02-13 14:40:36 -05:00
|
|
|
// External functions are assumed unsafe,
|
|
|
|
|
// unless //go:noescape is given before the declaration.
|
2016-10-12 11:34:47 +09:00
|
|
|
if fn.Nbody.Len() == 0 {
|
2017-02-27 19:56:38 +02:00
|
|
|
if fn.Noescape() {
|
2016-10-12 11:34:47 +09:00
|
|
|
for _, f := range fn.Type.Params().Fields().Slice() {
|
|
|
|
|
if haspointers(f.Type) {
|
|
|
|
|
f.Note = mktag(EscNone)
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
cmd/compile: recognize Syscall-like functions for liveness analysis
Consider this code:
func f(*int)
func g() {
p := new(int)
f(p)
}
where f is an assembly function.
In general liveness analysis assumes that during the call to f, p is dead
in this frame. If f has retained p, p will be found alive in f's frame and keep
the new(int) from being garbage collected. This is all correct and works.
We use the Go func declaration for f to give the assembly function
liveness information (the arguments are assumed live for the entire call).
Now consider this code:
func h1() {
p := new(int)
syscall.Syscall(1, 2, 3, uintptr(unsafe.Pointer(p)))
}
Here syscall.Syscall is taking the place of f, but because its arguments
are uintptr, the liveness analysis and the garbage collector ignore them.
Since p is no longer live in h once the call starts, if the garbage collector
scans the stack while the system call is blocked, it will find no reference
to the new(int) and reclaim it. If the kernel is going to write to *p once
the call finishes, reclaiming the memory is a mistake.
We can't change the arguments or the liveness information for
syscall.Syscall itself, both for compatibility and because sometimes the
arguments really are integers, and the garbage collector will get quite upset
if it finds an integer where it expects a pointer. The problem is that
these arguments are fundamentally untyped.
The solution we have taken in the syscall package's wrappers in past
releases is to insert a call to a dummy function named "use", to make
it look like the argument is live during the call to syscall.Syscall:
func h2() {
p := new(int)
syscall.Syscall(1, 2, 3, uintptr(unsafe.Pointer(p)))
use(unsafe.Pointer(p))
}
Keeping p alive during the call means that if the garbage collector
scans the stack during the system call now, it will find the reference to p.
Unfortunately, this approach is not available to users outside syscall,
because 'use' is unexported, and people also have to realize they need
to use it and do so. There is much existing code using syscall.Syscall
without a 'use'-like function. That code will fail very occasionally in
mysterious ways (see #13372).
This CL fixes all that existing code by making the compiler do the right
thing automatically, without any code modifications. That is, it takes h1
above, which is incorrect code today, and makes it correct code.
Specifically, if the compiler sees a foreign func definition (one
without a body) that has uintptr arguments, it marks those arguments
as "unsafe uintptrs". If it later sees the function being called
with uintptr(unsafe.Pointer(x)) as an argument, it arranges to mark x
as having escaped, and it makes sure to hold x in a live temporary
variable until the call returns, so that the garbage collector cannot
reclaim whatever heap memory x points to.
For now I am leaving the explicit calls to use in package syscall,
but they can be removed early in a future cycle (likely Go 1.7).
The rule has no effect on escape analysis, only on liveness analysis.
Fixes #13372.
Change-Id: I2addb83f70d08db08c64d394f9d06ff0a063c500
Reviewed-on: https://go-review.googlesource.com/18584
Reviewed-by: Ian Lance Taylor <iant@golang.org>
2016-01-13 00:46:28 -05:00
|
|
|
// Assume that uintptr arguments must be held live across the call.
|
|
|
|
|
// This is most important for syscall.Syscall.
|
|
|
|
|
// See golang.org/issue/13372.
|
|
|
|
|
// This really doesn't have much to do with escape analysis per se,
|
|
|
|
|
// but we are reusing the ability to annotate an individual function
|
|
|
|
|
// argument and pass those annotations along to importing code.
|
|
|
|
|
narg := 0
|
2016-10-12 11:34:47 +09:00
|
|
|
for _, f := range fn.Type.Params().Fields().Slice() {
|
cmd/compile: recognize Syscall-like functions for liveness analysis
Consider this code:
func f(*int)
func g() {
p := new(int)
f(p)
}
where f is an assembly function.
In general liveness analysis assumes that during the call to f, p is dead
in this frame. If f has retained p, p will be found alive in f's frame and keep
the new(int) from being garbage collected. This is all correct and works.
We use the Go func declaration for f to give the assembly function
liveness information (the arguments are assumed live for the entire call).
Now consider this code:
func h1() {
p := new(int)
syscall.Syscall(1, 2, 3, uintptr(unsafe.Pointer(p)))
}
Here syscall.Syscall is taking the place of f, but because its arguments
are uintptr, the liveness analysis and the garbage collector ignore them.
Since p is no longer live in h once the call starts, if the garbage collector
scans the stack while the system call is blocked, it will find no reference
to the new(int) and reclaim it. If the kernel is going to write to *p once
the call finishes, reclaiming the memory is a mistake.
We can't change the arguments or the liveness information for
syscall.Syscall itself, both for compatibility and because sometimes the
arguments really are integers, and the garbage collector will get quite upset
if it finds an integer where it expects a pointer. The problem is that
these arguments are fundamentally untyped.
The solution we have taken in the syscall package's wrappers in past
releases is to insert a call to a dummy function named "use", to make
it look like the argument is live during the call to syscall.Syscall:
func h2() {
p := new(int)
syscall.Syscall(1, 2, 3, uintptr(unsafe.Pointer(p)))
use(unsafe.Pointer(p))
}
Keeping p alive during the call means that if the garbage collector
scans the stack during the system call now, it will find the reference to p.
Unfortunately, this approach is not available to users outside syscall,
because 'use' is unexported, and people also have to realize they need
to use it and do so. There is much existing code using syscall.Syscall
without a 'use'-like function. That code will fail very occasionally in
mysterious ways (see #13372).
This CL fixes all that existing code by making the compiler do the right
thing automatically, without any code modifications. That is, it takes h1
above, which is incorrect code today, and makes it correct code.
Specifically, if the compiler sees a foreign func definition (one
without a body) that has uintptr arguments, it marks those arguments
as "unsafe uintptrs". If it later sees the function being called
with uintptr(unsafe.Pointer(x)) as an argument, it arranges to mark x
as having escaped, and it makes sure to hold x in a live temporary
variable until the call returns, so that the garbage collector cannot
reclaim whatever heap memory x points to.
For now I am leaving the explicit calls to use in package syscall,
but they can be removed early in a future cycle (likely Go 1.7).
The rule has no effect on escape analysis, only on liveness analysis.
Fixes #13372.
Change-Id: I2addb83f70d08db08c64d394f9d06ff0a063c500
Reviewed-on: https://go-review.googlesource.com/18584
Reviewed-by: Ian Lance Taylor <iant@golang.org>
2016-01-13 00:46:28 -05:00
|
|
|
narg++
|
2016-10-12 11:34:47 +09:00
|
|
|
if f.Type.Etype == TUINTPTR {
|
cmd/compile: recognize Syscall-like functions for liveness analysis
Consider this code:
func f(*int)
func g() {
p := new(int)
f(p)
}
where f is an assembly function.
In general liveness analysis assumes that during the call to f, p is dead
in this frame. If f has retained p, p will be found alive in f's frame and keep
the new(int) from being garbage collected. This is all correct and works.
We use the Go func declaration for f to give the assembly function
liveness information (the arguments are assumed live for the entire call).
Now consider this code:
func h1() {
p := new(int)
syscall.Syscall(1, 2, 3, uintptr(unsafe.Pointer(p)))
}
Here syscall.Syscall is taking the place of f, but because its arguments
are uintptr, the liveness analysis and the garbage collector ignore them.
Since p is no longer live in h once the call starts, if the garbage collector
scans the stack while the system call is blocked, it will find no reference
to the new(int) and reclaim it. If the kernel is going to write to *p once
the call finishes, reclaiming the memory is a mistake.
We can't change the arguments or the liveness information for
syscall.Syscall itself, both for compatibility and because sometimes the
arguments really are integers, and the garbage collector will get quite upset
if it finds an integer where it expects a pointer. The problem is that
these arguments are fundamentally untyped.
The solution we have taken in the syscall package's wrappers in past
releases is to insert a call to a dummy function named "use", to make
it look like the argument is live during the call to syscall.Syscall:
func h2() {
p := new(int)
syscall.Syscall(1, 2, 3, uintptr(unsafe.Pointer(p)))
use(unsafe.Pointer(p))
}
Keeping p alive during the call means that if the garbage collector
scans the stack during the system call now, it will find the reference to p.
Unfortunately, this approach is not available to users outside syscall,
because 'use' is unexported, and people also have to realize they need
to use it and do so. There is much existing code using syscall.Syscall
without a 'use'-like function. That code will fail very occasionally in
mysterious ways (see #13372).
This CL fixes all that existing code by making the compiler do the right
thing automatically, without any code modifications. That is, it takes h1
above, which is incorrect code today, and makes it correct code.
Specifically, if the compiler sees a foreign func definition (one
without a body) that has uintptr arguments, it marks those arguments
as "unsafe uintptrs". If it later sees the function being called
with uintptr(unsafe.Pointer(x)) as an argument, it arranges to mark x
as having escaped, and it makes sure to hold x in a live temporary
variable until the call returns, so that the garbage collector cannot
reclaim whatever heap memory x points to.
For now I am leaving the explicit calls to use in package syscall,
but they can be removed early in a future cycle (likely Go 1.7).
The rule has no effect on escape analysis, only on liveness analysis.
Fixes #13372.
Change-Id: I2addb83f70d08db08c64d394f9d06ff0a063c500
Reviewed-on: https://go-review.googlesource.com/18584
Reviewed-by: Ian Lance Taylor <iant@golang.org>
2016-01-13 00:46:28 -05:00
|
|
|
if Debug['m'] != 0 {
|
2016-12-07 17:40:46 -08:00
|
|
|
Warnl(fn.Pos, "%v assuming %v is unsafe uintptr", funcSym(fn), name(f.Sym, narg))
|
cmd/compile: recognize Syscall-like functions for liveness analysis
Consider this code:
func f(*int)
func g() {
p := new(int)
f(p)
}
where f is an assembly function.
In general liveness analysis assumes that during the call to f, p is dead
in this frame. If f has retained p, p will be found alive in f's frame and keep
the new(int) from being garbage collected. This is all correct and works.
We use the Go func declaration for f to give the assembly function
liveness information (the arguments are assumed live for the entire call).
Now consider this code:
func h1() {
p := new(int)
syscall.Syscall(1, 2, 3, uintptr(unsafe.Pointer(p)))
}
Here syscall.Syscall is taking the place of f, but because its arguments
are uintptr, the liveness analysis and the garbage collector ignore them.
Since p is no longer live in h once the call starts, if the garbage collector
scans the stack while the system call is blocked, it will find no reference
to the new(int) and reclaim it. If the kernel is going to write to *p once
the call finishes, reclaiming the memory is a mistake.
We can't change the arguments or the liveness information for
syscall.Syscall itself, both for compatibility and because sometimes the
arguments really are integers, and the garbage collector will get quite upset
if it finds an integer where it expects a pointer. The problem is that
these arguments are fundamentally untyped.
The solution we have taken in the syscall package's wrappers in past
releases is to insert a call to a dummy function named "use", to make
it look like the argument is live during the call to syscall.Syscall:
func h2() {
p := new(int)
syscall.Syscall(1, 2, 3, uintptr(unsafe.Pointer(p)))
use(unsafe.Pointer(p))
}
Keeping p alive during the call means that if the garbage collector
scans the stack during the system call now, it will find the reference to p.
Unfortunately, this approach is not available to users outside syscall,
because 'use' is unexported, and people also have to realize they need
to use it and do so. There is much existing code using syscall.Syscall
without a 'use'-like function. That code will fail very occasionally in
mysterious ways (see #13372).
This CL fixes all that existing code by making the compiler do the right
thing automatically, without any code modifications. That is, it takes h1
above, which is incorrect code today, and makes it correct code.
Specifically, if the compiler sees a foreign func definition (one
without a body) that has uintptr arguments, it marks those arguments
as "unsafe uintptrs". If it later sees the function being called
with uintptr(unsafe.Pointer(x)) as an argument, it arranges to mark x
as having escaped, and it makes sure to hold x in a live temporary
variable until the call returns, so that the garbage collector cannot
reclaim whatever heap memory x points to.
For now I am leaving the explicit calls to use in package syscall,
but they can be removed early in a future cycle (likely Go 1.7).
The rule has no effect on escape analysis, only on liveness analysis.
Fixes #13372.
Change-Id: I2addb83f70d08db08c64d394f9d06ff0a063c500
Reviewed-on: https://go-review.googlesource.com/18584
Reviewed-by: Ian Lance Taylor <iant@golang.org>
2016-01-13 00:46:28 -05:00
|
|
|
}
|
2016-10-12 11:34:47 +09:00
|
|
|
f.Note = unsafeUintptrTag
|
cmd/compile: recognize Syscall-like functions for liveness analysis
Consider this code:
func f(*int)
func g() {
p := new(int)
f(p)
}
where f is an assembly function.
In general liveness analysis assumes that during the call to f, p is dead
in this frame. If f has retained p, p will be found alive in f's frame and keep
the new(int) from being garbage collected. This is all correct and works.
We use the Go func declaration for f to give the assembly function
liveness information (the arguments are assumed live for the entire call).
Now consider this code:
func h1() {
p := new(int)
syscall.Syscall(1, 2, 3, uintptr(unsafe.Pointer(p)))
}
Here syscall.Syscall is taking the place of f, but because its arguments
are uintptr, the liveness analysis and the garbage collector ignore them.
Since p is no longer live in h once the call starts, if the garbage collector
scans the stack while the system call is blocked, it will find no reference
to the new(int) and reclaim it. If the kernel is going to write to *p once
the call finishes, reclaiming the memory is a mistake.
We can't change the arguments or the liveness information for
syscall.Syscall itself, both for compatibility and because sometimes the
arguments really are integers, and the garbage collector will get quite upset
if it finds an integer where it expects a pointer. The problem is that
these arguments are fundamentally untyped.
The solution we have taken in the syscall package's wrappers in past
releases is to insert a call to a dummy function named "use", to make
it look like the argument is live during the call to syscall.Syscall:
func h2() {
p := new(int)
syscall.Syscall(1, 2, 3, uintptr(unsafe.Pointer(p)))
use(unsafe.Pointer(p))
}
Keeping p alive during the call means that if the garbage collector
scans the stack during the system call now, it will find the reference to p.
Unfortunately, this approach is not available to users outside syscall,
because 'use' is unexported, and people also have to realize they need
to use it and do so. There is much existing code using syscall.Syscall
without a 'use'-like function. That code will fail very occasionally in
mysterious ways (see #13372).
This CL fixes all that existing code by making the compiler do the right
thing automatically, without any code modifications. That is, it takes h1
above, which is incorrect code today, and makes it correct code.
Specifically, if the compiler sees a foreign func definition (one
without a body) that has uintptr arguments, it marks those arguments
as "unsafe uintptrs". If it later sees the function being called
with uintptr(unsafe.Pointer(x)) as an argument, it arranges to mark x
as having escaped, and it makes sure to hold x in a live temporary
variable until the call returns, so that the garbage collector cannot
reclaim whatever heap memory x points to.
For now I am leaving the explicit calls to use in package syscall,
but they can be removed early in a future cycle (likely Go 1.7).
The rule has no effect on escape analysis, only on liveness analysis.
Fixes #13372.
Change-Id: I2addb83f70d08db08c64d394f9d06ff0a063c500
Reviewed-on: https://go-review.googlesource.com/18584
Reviewed-by: Ian Lance Taylor <iant@golang.org>
2016-01-13 00:46:28 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2015-02-13 14:40:36 -05:00
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-12 11:34:47 +09:00
|
|
|
if fn.Func.Pragma&UintptrEscapes != 0 {
|
2016-06-28 14:19:27 -07:00
|
|
|
narg := 0
|
2016-10-12 11:34:47 +09:00
|
|
|
for _, f := range fn.Type.Params().Fields().Slice() {
|
2016-06-28 14:19:27 -07:00
|
|
|
narg++
|
2016-10-12 11:34:47 +09:00
|
|
|
if f.Type.Etype == TUINTPTR {
|
2016-06-28 14:19:27 -07:00
|
|
|
if Debug['m'] != 0 {
|
2016-12-07 17:40:46 -08:00
|
|
|
Warnl(fn.Pos, "%v marking %v as escaping uintptr", funcSym(fn), name(f.Sym, narg))
|
2016-06-28 14:19:27 -07:00
|
|
|
}
|
2016-10-12 11:34:47 +09:00
|
|
|
f.Note = uintptrEscapesTag
|
2016-06-28 14:19:27 -07:00
|
|
|
}
|
|
|
|
|
|
2017-02-27 19:56:38 +02:00
|
|
|
if f.Isddd() && f.Type.Elem().Etype == TUINTPTR {
|
2016-06-28 14:19:27 -07:00
|
|
|
// final argument is ...uintptr.
|
|
|
|
|
if Debug['m'] != 0 {
|
2016-12-07 17:40:46 -08:00
|
|
|
Warnl(fn.Pos, "%v marking %v as escaping ...uintptr", funcSym(fn), name(f.Sym, narg))
|
2016-06-28 14:19:27 -07:00
|
|
|
}
|
2016-10-12 11:34:47 +09:00
|
|
|
f.Note = uintptrEscapesTag
|
2016-06-28 14:19:27 -07:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-12 11:34:47 +09:00
|
|
|
for _, ln := range fn.Func.Dcl {
|
2016-02-25 10:35:19 -08:00
|
|
|
if ln.Op != ONAME {
|
2015-02-13 14:40:36 -05:00
|
|
|
continue
|
|
|
|
|
}
|
|
|
|
|
|
2016-02-25 10:35:19 -08:00
|
|
|
switch ln.Esc & EscMask {
|
2015-02-13 14:40:36 -05:00
|
|
|
case EscNone, // not touched by escflood
|
|
|
|
|
EscReturn:
|
2016-02-25 10:35:19 -08:00
|
|
|
if haspointers(ln.Type) { // don't bother tagging for scalars
|
2016-06-28 14:19:27 -07:00
|
|
|
if ln.Name.Param.Field.Note != uintptrEscapesTag {
|
|
|
|
|
ln.Name.Param.Field.Note = mktag(int(ln.Esc))
|
|
|
|
|
}
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
|
2016-10-26 11:44:26 +09:00
|
|
|
case EscHeap: // touched by escflood, moved to heap
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|
|
|
|
|
}
|
2017-03-24 09:00:17 -07:00
|
|
|
|
|
|
|
|
// Unnamed parameters are unused and therefore do not escape.
|
|
|
|
|
// (Unnamed parameters are not in the Dcl list in the loop above
|
|
|
|
|
// so we need to mark them separately.)
|
|
|
|
|
for _, f := range fn.Type.Params().Fields().Slice() {
|
|
|
|
|
if f.Sym == nil || isblanksym(f.Sym) {
|
|
|
|
|
f.Note = mktag(EscNone)
|
|
|
|
|
}
|
|
|
|
|
}
|
2015-02-13 14:40:36 -05:00
|
|
|
}
|