| 
									
										
											  
											
												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
										 |  |  | // errorcheck -0 -m -l | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2016-04-10 14:32:26 -07:00
										 |  |  | // Copyright 2015 The Go Authors. All rights reserved. | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | // Use of this source code is governed by a BSD-style | 
					
						
							|  |  |  | // license that can be found in the LICENSE file. | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | // Test escape analysis for *struct function parameters. | 
					
						
							|  |  |  | // Note companion strict_param2 checks struct function parameters with similar tests. | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | package notmain | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | var Ssink *string | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | type U struct { | 
					
						
							|  |  |  | 	_sp  *string | 
					
						
							|  |  |  | 	_spp **string | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | type V struct { | 
					
						
							|  |  |  | 	_u   U | 
					
						
							|  |  |  | 	_up  *U | 
					
						
							|  |  |  | 	_upp **U | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | func (u *U) SP() *string { // ERROR "leaking param: u to result ~r0 level=1$" | 
					
						
							|  |  |  | 	return u._sp | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | func (u *U) SPP() **string { // ERROR "leaking param: u to result ~r0 level=1$" | 
					
						
							|  |  |  | 	return u._spp | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | func (u *U) SPPi() *string { // ERROR "leaking param: u to result ~r0 level=2$" | 
					
						
							|  |  |  | 	return *u._spp | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | func tSPPi() { | 
					
						
							|  |  |  | 	s := "cat"        // ERROR "moved to heap: s$" | 
					
						
							| 
									
										
										
										
											2019-04-01 11:58:33 -07:00
										 |  |  | 	ps := &s | 
					
						
							|  |  |  | 	pps := &ps | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 	pu := &U{ps, pps} // ERROR "tSPPi &U literal does not escape$" | 
					
						
							|  |  |  | 	Ssink = pu.SPPi() | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | func tiSPP() { | 
					
						
							|  |  |  | 	s := "cat"        // ERROR "moved to heap: s$" | 
					
						
							| 
									
										
										
										
											2019-04-01 11:58:33 -07:00
										 |  |  | 	ps := &s | 
					
						
							|  |  |  | 	pps := &ps | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 	pu := &U{ps, pps} // ERROR "tiSPP &U literal does not escape$" | 
					
						
							|  |  |  | 	Ssink = *pu.SPP() | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | // BAD: need fine-grained (field-sensitive) analysis to avoid spurious escape of ps | 
					
						
							|  |  |  | func tSP() { | 
					
						
							|  |  |  | 	s := "cat"        // ERROR "moved to heap: s$" | 
					
						
							| 
									
										
										
										
											2019-04-01 11:58:33 -07:00
										 |  |  | 	ps := &s          // ERROR "moved to heap: ps$" | 
					
						
							|  |  |  | 	pps := &ps | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 	pu := &U{ps, pps} // ERROR "tSP &U literal does not escape$" | 
					
						
							|  |  |  | 	Ssink = pu.SP() | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | func (v *V) u() U { // ERROR "leaking param: v to result ~r0 level=1$" | 
					
						
							|  |  |  | 	return v._u | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | func (v *V) UP() *U { // ERROR "leaking param: v to result ~r0 level=1$" | 
					
						
							|  |  |  | 	return v._up | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | func (v *V) UPP() **U { // ERROR "leaking param: v to result ~r0 level=1$" | 
					
						
							|  |  |  | 	return v._upp | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | func (v *V) UPPia() *U { // ERROR "leaking param: v to result ~r0 level=2$" | 
					
						
							|  |  |  | 	return *v._upp | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | func (v *V) UPPib() *U { // ERROR "leaking param: v to result ~r0 level=2$" | 
					
						
							|  |  |  | 	return *v.UPP() | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | func (v *V) USPa() *string { // ERROR "leaking param: v to result ~r0 level=1$" | 
					
						
							|  |  |  | 	return v._u._sp | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | func (v *V) USPb() *string { // ERROR "leaking param: v to result ~r0 level=1$" | 
					
						
							|  |  |  | 	return v.u()._sp | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | func (v *V) USPPia() *string { // ERROR "leaking param: v to result ~r0 level=2$" | 
					
						
							|  |  |  | 	return *v._u._spp | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | func (v *V) USPPib() *string { // ERROR "leaking param: v to result ~r0 level=2$" | 
					
						
							| 
									
										
										
										
											2019-04-01 11:58:33 -07:00
										 |  |  | 	return v._u.SPPi() | 
					
						
							| 
									
										
											  
											
												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 (v *V) UPiSPa() *string { // ERROR "leaking param: v to result ~r0 level=2$" | 
					
						
							|  |  |  | 	return v._up._sp | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | func (v *V) UPiSPb() *string { // ERROR "leaking param: v to result ~r0 level=2$" | 
					
						
							|  |  |  | 	return v._up.SP() | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | func (v *V) UPiSPc() *string { // ERROR "leaking param: v to result ~r0 level=2$" | 
					
						
							|  |  |  | 	return v.UP()._sp | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | func (v *V) UPiSPd() *string { // ERROR "leaking param: v to result ~r0 level=2$" | 
					
						
							|  |  |  | 	return v.UP().SP() | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | // BAD: need fine-grained (field-sensitive) analysis to avoid spurious escape of all but &s3 | 
					
						
							|  |  |  | func tUPiSPa() { | 
					
						
							|  |  |  | 	s1 := "ant" | 
					
						
							|  |  |  | 	s2 := "bat"          // ERROR "moved to heap: s2$" | 
					
						
							|  |  |  | 	s3 := "cat"          // ERROR "moved to heap: s3$" | 
					
						
							|  |  |  | 	s4 := "dog"          // ERROR "moved to heap: s4$" | 
					
						
							|  |  |  | 	s5 := "emu"          // ERROR "moved to heap: s5$" | 
					
						
							|  |  |  | 	s6 := "fox"          // ERROR "moved to heap: s6$" | 
					
						
							| 
									
										
										
										
											2019-04-01 11:58:33 -07:00
										 |  |  | 	ps2 := &s2 | 
					
						
							|  |  |  | 	ps4 := &s4           // ERROR "moved to heap: ps4$" | 
					
						
							|  |  |  | 	ps6 := &s6           // ERROR "moved to heap: ps6$" | 
					
						
							|  |  |  | 	u1 := U{&s1, &ps2} | 
					
						
							|  |  |  | 	u2 := &U{&s3, &ps4}  // ERROR "tUPiSPa &U literal does not escape$" | 
					
						
							|  |  |  | 	u3 := &U{&s5, &ps6}  // ERROR "&U literal escapes to heap$" | 
					
						
							|  |  |  | 	v := &V{u1, u2, &u3} // ERROR "tUPiSPa &V literal does not escape$" | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 	Ssink = v.UPiSPa()   // Ssink = &s3 (only &s3 really escapes) | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | // BAD: need fine-grained (field-sensitive) analysis to avoid spurious escape of all but &s3 | 
					
						
							|  |  |  | func tUPiSPb() { | 
					
						
							|  |  |  | 	s1 := "ant" | 
					
						
							|  |  |  | 	s2 := "bat"          // ERROR "moved to heap: s2$" | 
					
						
							|  |  |  | 	s3 := "cat"          // ERROR "moved to heap: s3$" | 
					
						
							|  |  |  | 	s4 := "dog"          // ERROR "moved to heap: s4$" | 
					
						
							|  |  |  | 	s5 := "emu"          // ERROR "moved to heap: s5$" | 
					
						
							|  |  |  | 	s6 := "fox"          // ERROR "moved to heap: s6$" | 
					
						
							| 
									
										
										
										
											2019-04-01 11:58:33 -07:00
										 |  |  | 	ps2 := &s2 | 
					
						
							|  |  |  | 	ps4 := &s4           // ERROR "moved to heap: ps4$" | 
					
						
							|  |  |  | 	ps6 := &s6           // ERROR "moved to heap: ps6$" | 
					
						
							|  |  |  | 	u1 := U{&s1, &ps2} | 
					
						
							|  |  |  | 	u2 := &U{&s3, &ps4}  // ERROR "tUPiSPb &U literal does not escape$" | 
					
						
							|  |  |  | 	u3 := &U{&s5, &ps6}  // ERROR "&U literal escapes to heap$" | 
					
						
							|  |  |  | 	v := &V{u1, u2, &u3} // ERROR "tUPiSPb &V literal does not escape$" | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 	Ssink = v.UPiSPb()   // Ssink = &s3 (only &s3 really escapes) | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | // BAD: need fine-grained (field-sensitive) analysis to avoid spurious escape of all but &s3 | 
					
						
							|  |  |  | func tUPiSPc() { | 
					
						
							|  |  |  | 	s1 := "ant" | 
					
						
							|  |  |  | 	s2 := "bat"          // ERROR "moved to heap: s2$" | 
					
						
							|  |  |  | 	s3 := "cat"          // ERROR "moved to heap: s3$" | 
					
						
							|  |  |  | 	s4 := "dog"          // ERROR "moved to heap: s4$" | 
					
						
							|  |  |  | 	s5 := "emu"          // ERROR "moved to heap: s5$" | 
					
						
							|  |  |  | 	s6 := "fox"          // ERROR "moved to heap: s6$" | 
					
						
							| 
									
										
										
										
											2019-04-01 11:58:33 -07:00
										 |  |  | 	ps2 := &s2 | 
					
						
							|  |  |  | 	ps4 := &s4           // ERROR "moved to heap: ps4$" | 
					
						
							|  |  |  | 	ps6 := &s6           // ERROR "moved to heap: ps6$" | 
					
						
							|  |  |  | 	u1 := U{&s1, &ps2} | 
					
						
							|  |  |  | 	u2 := &U{&s3, &ps4}  // ERROR "tUPiSPc &U literal does not escape$" | 
					
						
							|  |  |  | 	u3 := &U{&s5, &ps6}  // ERROR "&U literal escapes to heap$" | 
					
						
							|  |  |  | 	v := &V{u1, u2, &u3} // ERROR "tUPiSPc &V literal does not escape$" | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 	Ssink = v.UPiSPc()   // Ssink = &s3 (only &s3 really escapes) | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | // BAD: need fine-grained (field-sensitive) analysis to avoid spurious escape of all but &s3 | 
					
						
							|  |  |  | func tUPiSPd() { | 
					
						
							|  |  |  | 	s1 := "ant" | 
					
						
							|  |  |  | 	s2 := "bat"          // ERROR "moved to heap: s2$" | 
					
						
							|  |  |  | 	s3 := "cat"          // ERROR "moved to heap: s3$" | 
					
						
							|  |  |  | 	s4 := "dog"          // ERROR "moved to heap: s4$" | 
					
						
							|  |  |  | 	s5 := "emu"          // ERROR "moved to heap: s5$" | 
					
						
							|  |  |  | 	s6 := "fox"          // ERROR "moved to heap: s6$" | 
					
						
							| 
									
										
										
										
											2019-04-01 11:58:33 -07:00
										 |  |  | 	ps2 := &s2 | 
					
						
							|  |  |  | 	ps4 := &s4           // ERROR "moved to heap: ps4$" | 
					
						
							|  |  |  | 	ps6 := &s6           // ERROR "moved to heap: ps6$" | 
					
						
							|  |  |  | 	u1 := U{&s1, &ps2} | 
					
						
							|  |  |  | 	u2 := &U{&s3, &ps4}  // ERROR "tUPiSPd &U literal does not escape$" | 
					
						
							|  |  |  | 	u3 := &U{&s5, &ps6}  // ERROR "&U literal escapes to heap$" | 
					
						
							|  |  |  | 	v := &V{u1, u2, &u3} // ERROR "tUPiSPd &V literal does not escape$" | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 	Ssink = v.UPiSPd()   // Ssink = &s3 (only &s3 really escapes) | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | func (v V) UPiSPPia() *string { // ERROR "leaking param: v to result ~r0 level=2$" | 
					
						
							|  |  |  | 	return *v._up._spp | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | func (v V) UPiSPPib() *string { // ERROR "leaking param: v to result ~r0 level=2$" | 
					
						
							|  |  |  | 	return v._up.SPPi() | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | func (v V) UPiSPPic() *string { // ERROR "leaking param: v to result ~r0 level=2$" | 
					
						
							| 
									
										
										
										
											2019-04-01 11:58:33 -07:00
										 |  |  | 	return *v.UP()._spp | 
					
						
							| 
									
										
											  
											
												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 (v V) UPiSPPid() *string { // ERROR "leaking param: v to result ~r0 level=2$" | 
					
						
							| 
									
										
										
										
											2019-04-01 11:58:33 -07:00
										 |  |  | 	return v.UP().SPPi() | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | // BAD: need fine-grained (field-sensitive) analysis to avoid spurious escape of all but &s4 | 
					
						
							|  |  |  | func tUPiSPPia() { | 
					
						
							|  |  |  | 	s1 := "ant" | 
					
						
							|  |  |  | 	s2 := "bat" | 
					
						
							|  |  |  | 	s3 := "cat" | 
					
						
							|  |  |  | 	s4 := "dog"          // ERROR "moved to heap: s4$" | 
					
						
							|  |  |  | 	s5 := "emu"          // ERROR "moved to heap: s5$" | 
					
						
							|  |  |  | 	s6 := "fox"          // ERROR "moved to heap: s6$" | 
					
						
							| 
									
										
										
										
											2019-04-01 11:58:33 -07:00
										 |  |  | 	ps2 := &s2 | 
					
						
							|  |  |  | 	ps4 := &s4 | 
					
						
							|  |  |  | 	ps6 := &s6           // ERROR "moved to heap: ps6$" | 
					
						
							|  |  |  | 	u1 := U{&s1, &ps2} | 
					
						
							|  |  |  | 	u2 := &U{&s3, &ps4}  // ERROR "tUPiSPPia &U literal does not escape$" | 
					
						
							|  |  |  | 	u3 := &U{&s5, &ps6}  // ERROR "tUPiSPPia &U literal does not escape$" | 
					
						
							|  |  |  | 	v := &V{u1, u2, &u3} // ERROR "tUPiSPPia &V literal does not escape$" | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 	Ssink = v.UPiSPPia() // Ssink = *&ps4 = &s4 (only &s4 really escapes) | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | // BAD: need fine-grained (field-sensitive) analysis to avoid spurious escape of all but &s4 | 
					
						
							|  |  |  | func tUPiSPPib() { | 
					
						
							|  |  |  | 	s1 := "ant" | 
					
						
							|  |  |  | 	s2 := "bat" | 
					
						
							|  |  |  | 	s3 := "cat" | 
					
						
							|  |  |  | 	s4 := "dog"          // ERROR "moved to heap: s4$" | 
					
						
							|  |  |  | 	s5 := "emu"          // ERROR "moved to heap: s5$" | 
					
						
							|  |  |  | 	s6 := "fox"          // ERROR "moved to heap: s6$" | 
					
						
							| 
									
										
										
										
											2019-04-01 11:58:33 -07:00
										 |  |  | 	ps2 := &s2 | 
					
						
							|  |  |  | 	ps4 := &s4 | 
					
						
							|  |  |  | 	ps6 := &s6           // ERROR "moved to heap: ps6$" | 
					
						
							|  |  |  | 	u1 := U{&s1, &ps2} | 
					
						
							|  |  |  | 	u2 := &U{&s3, &ps4}  // ERROR "tUPiSPPib &U literal does not escape$" | 
					
						
							|  |  |  | 	u3 := &U{&s5, &ps6}  // ERROR "tUPiSPPib &U literal does not escape$" | 
					
						
							|  |  |  | 	v := &V{u1, u2, &u3} // ERROR "tUPiSPPib &V literal does not escape$" | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 	Ssink = v.UPiSPPib() // Ssink = *&ps4 = &s4 (only &s4 really escapes) | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | // BAD: need fine-grained (field-sensitive) analysis to avoid spurious escape of all but &s4 | 
					
						
							|  |  |  | func tUPiSPPic() { | 
					
						
							|  |  |  | 	s1 := "ant" | 
					
						
							|  |  |  | 	s2 := "bat" | 
					
						
							|  |  |  | 	s3 := "cat" | 
					
						
							|  |  |  | 	s4 := "dog"          // ERROR "moved to heap: s4$" | 
					
						
							|  |  |  | 	s5 := "emu"          // ERROR "moved to heap: s5$" | 
					
						
							|  |  |  | 	s6 := "fox"          // ERROR "moved to heap: s6$" | 
					
						
							| 
									
										
										
										
											2019-04-01 11:58:33 -07:00
										 |  |  | 	ps2 := &s2 | 
					
						
							|  |  |  | 	ps4 := &s4 | 
					
						
							|  |  |  | 	ps6 := &s6           // ERROR "moved to heap: ps6$" | 
					
						
							|  |  |  | 	u1 := U{&s1, &ps2} | 
					
						
							|  |  |  | 	u2 := &U{&s3, &ps4}  // ERROR "tUPiSPPic &U literal does not escape$" | 
					
						
							|  |  |  | 	u3 := &U{&s5, &ps6}  // ERROR "tUPiSPPic &U literal does not escape$" | 
					
						
							|  |  |  | 	v := &V{u1, u2, &u3} // ERROR "tUPiSPPic &V literal does not escape$" | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 	Ssink = v.UPiSPPic() // Ssink = *&ps4 = &s4 (only &s4 really escapes) | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | // BAD: need fine-grained (field-sensitive) analysis to avoid spurious escape of all but &s4 | 
					
						
							|  |  |  | func tUPiSPPid() { | 
					
						
							|  |  |  | 	s1 := "ant" | 
					
						
							|  |  |  | 	s2 := "bat" | 
					
						
							|  |  |  | 	s3 := "cat" | 
					
						
							|  |  |  | 	s4 := "dog"          // ERROR "moved to heap: s4$" | 
					
						
							|  |  |  | 	s5 := "emu"          // ERROR "moved to heap: s5$" | 
					
						
							|  |  |  | 	s6 := "fox"          // ERROR "moved to heap: s6$" | 
					
						
							| 
									
										
										
										
											2019-04-01 11:58:33 -07:00
										 |  |  | 	ps2 := &s2 | 
					
						
							|  |  |  | 	ps4 := &s4 | 
					
						
							|  |  |  | 	ps6 := &s6           // ERROR "moved to heap: ps6$" | 
					
						
							|  |  |  | 	u1 := U{&s1, &ps2} | 
					
						
							|  |  |  | 	u2 := &U{&s3, &ps4}  // ERROR "tUPiSPPid &U literal does not escape$" | 
					
						
							|  |  |  | 	u3 := &U{&s5, &ps6}  // ERROR "tUPiSPPid &U literal does not escape$" | 
					
						
							|  |  |  | 	v := &V{u1, u2, &u3} // ERROR "tUPiSPPid &V literal does not escape$" | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 	Ssink = v.UPiSPPid() // Ssink = *&ps4 = &s4 (only &s4 really escapes) | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | func (v *V) UPPiSPPia() *string { // ERROR "leaking param: v to result ~r0 level=4$" | 
					
						
							|  |  |  | 	return *(*v._upp)._spp | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | // This test isolates the one value that needs to escape, not because | 
					
						
							|  |  |  | // it distinguishes fields but because it knows that &s6 is the only | 
					
						
							|  |  |  | // value reachable by two indirects from v. | 
					
						
							|  |  |  | // The test depends on the level cap in the escape analysis tags | 
					
						
							|  |  |  | // being able to encode that fact. | 
					
						
							|  |  |  | func tUPPiSPPia() { | 
					
						
							|  |  |  | 	s1 := "ant" | 
					
						
							|  |  |  | 	s2 := "bat" | 
					
						
							|  |  |  | 	s3 := "cat" | 
					
						
							|  |  |  | 	s4 := "dog" | 
					
						
							|  |  |  | 	s5 := "emu" | 
					
						
							|  |  |  | 	s6 := "fox"           // ERROR "moved to heap: s6$" | 
					
						
							| 
									
										
										
										
											2019-04-01 11:58:33 -07:00
										 |  |  | 	ps2 := &s2 | 
					
						
							|  |  |  | 	ps4 := &s4 | 
					
						
							|  |  |  | 	ps6 := &s6 | 
					
						
							|  |  |  | 	u1 := U{&s1, &ps2} | 
					
						
							|  |  |  | 	u2 := &U{&s3, &ps4}   // ERROR "tUPPiSPPia &U literal does not escape$" | 
					
						
							|  |  |  | 	u3 := &U{&s5, &ps6}   // ERROR "tUPPiSPPia &U literal does not escape$" | 
					
						
							|  |  |  | 	v := &V{u1, u2, &u3}  // ERROR "tUPPiSPPia &V literal does not escape$" | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 	Ssink = v.UPPiSPPia() // Ssink = *&ps6 = &s6 (only &s6 really escapes) | 
					
						
							|  |  |  | } |