1
0
mirror of https://github.com/golang/go synced 2024-11-12 05:40:22 -07:00
go/test/live.go

646 lines
18 KiB
Go
Raw Normal View History

// +build !amd64
cmd/gc: emit write barriers A write *p = x that needs a write barrier (not all do) now turns into runtime.writebarrierptr(p, x) or one of the other variants. The write barrier implementations are trivial. The goal here is to emit the calls in the correct places and to incur the cost of those function calls in the Go 1.4 cycle. Performance on the Go 1 benchmark suite below. Remember, the goal is to slow things down (and be correct). We will look into optimizations in separate CLs, as part of the process of comparing Go 1.3 against tip in order to make sure Go 1.4 runs at least as fast as Go 1.3. benchmark old ns/op new ns/op delta BenchmarkBinaryTree17 3118336716 3452876110 +10.73% BenchmarkFannkuch11 3184497677 3211552284 +0.85% BenchmarkFmtFprintfEmpty 89.9 107 +19.02% BenchmarkFmtFprintfString 236 287 +21.61% BenchmarkFmtFprintfInt 246 278 +13.01% BenchmarkFmtFprintfIntInt 395 458 +15.95% BenchmarkFmtFprintfPrefixedInt 343 378 +10.20% BenchmarkFmtFprintfFloat 477 525 +10.06% BenchmarkFmtManyArgs 1446 1707 +18.05% BenchmarkGobDecode 14398047 14685958 +2.00% BenchmarkGobEncode 12557718 12947104 +3.10% BenchmarkGzip 453462345 472413285 +4.18% BenchmarkGunzip 114226016 115127398 +0.79% BenchmarkHTTPClientServer 114689 112122 -2.24% BenchmarkJSONEncode 24914536 26135942 +4.90% BenchmarkJSONDecode 86832877 103620289 +19.33% BenchmarkMandelbrot200 4833452 4898780 +1.35% BenchmarkGoParse 4317976 4835474 +11.98% BenchmarkRegexpMatchEasy0_32 150 166 +10.67% BenchmarkRegexpMatchEasy0_1K 393 402 +2.29% BenchmarkRegexpMatchEasy1_32 125 142 +13.60% BenchmarkRegexpMatchEasy1_1K 1010 1236 +22.38% BenchmarkRegexpMatchMedium_32 232 301 +29.74% BenchmarkRegexpMatchMedium_1K 76963 102721 +33.47% BenchmarkRegexpMatchHard_32 3833 5463 +42.53% BenchmarkRegexpMatchHard_1K 119668 161614 +35.05% BenchmarkRevcomp 763449047 706768534 -7.42% BenchmarkTemplate 124954724 134834549 +7.91% BenchmarkTimeParse 517 511 -1.16% BenchmarkTimeFormat 501 514 +2.59% benchmark old MB/s new MB/s speedup BenchmarkGobDecode 53.31 52.26 0.98x BenchmarkGobEncode 61.12 59.28 0.97x BenchmarkGzip 42.79 41.08 0.96x BenchmarkGunzip 169.88 168.55 0.99x BenchmarkJSONEncode 77.89 74.25 0.95x BenchmarkJSONDecode 22.35 18.73 0.84x BenchmarkGoParse 13.41 11.98 0.89x BenchmarkRegexpMatchEasy0_32 213.30 191.72 0.90x BenchmarkRegexpMatchEasy0_1K 2603.92 2542.74 0.98x BenchmarkRegexpMatchEasy1_32 254.00 224.93 0.89x BenchmarkRegexpMatchEasy1_1K 1013.53 827.98 0.82x BenchmarkRegexpMatchMedium_32 4.30 3.31 0.77x BenchmarkRegexpMatchMedium_1K 13.30 9.97 0.75x BenchmarkRegexpMatchHard_32 8.35 5.86 0.70x BenchmarkRegexpMatchHard_1K 8.56 6.34 0.74x BenchmarkRevcomp 332.92 359.62 1.08x BenchmarkTemplate 15.53 14.39 0.93x LGTM=rlh R=rlh CC=dvyukov, golang-codereviews, iant, khr, r https://golang.org/cl/136380043
2014-09-11 10:17:45 -06:00
// errorcheck -0 -l -live -wb=0
cmd/gc: handle non-escaping address-taken variables better This CL makes the bitmaps a little more precise about variables that have their address taken but for which the address does not escape to the heap, so that the variables are kept in the stack frame rather than allocated on the heap. The code before this CL handled these variables by treating every return statement as using every such variable and depending on liveness analysis to essentially treat the variable as live during the entire function. That approach has false positives and (worse) false negatives. That is, it's both sloppy and buggy: func f(b1, b2 bool) { // x live here! (sloppy) if b2 { print(0) // x live here! (sloppy) return } var z **int x := new(int) *x = 42 z = &x print(**z) // x live here (conservative) if b2 { print(1) // x live here (conservative) return } for { print(**z) // x not live here (buggy) } } The first two liveness annotations (marked sloppy) are clearly wrong: x cannot be live if it has not yet been declared. The last liveness annotation (marked buggy) is also wrong: x is live here as *z, but because there is no return statement reachable from this point in the code, the analysis treats x as dead. This CL changes the liveness calculation to mark such variables live exactly at points in the code reachable from the variable declaration. This keeps the conservative decisions but fixes the sloppy and buggy ones. The CL also detects ambiguously live variables, those that are being marked live but may not actually have been initialized, such as in this example: func f(b1 bool) { var z **int if b1 { x := new(int) *x = 42 z = &x } else { y := new(int) *y = 54 z = &y } print(**z) // x, y live here (conservative) } Since the print statement is reachable from the declaration of x, x must conservatively be marked live. The same goes for y. Although both x and y are marked live at the print statement, clearly only one of them has been initialized. They are both "ambiguously live". These ambiguously live variables cause problems for garbage collection: the collector cannot ignore them but also cannot depend on them to be initialized to valid pointer values. Ambiguously live variables do not come up too often in real code, but recent changes to the way map and interface runtime functions are invoked has created a large number of ambiguously live compiler-generated temporary variables. The next CL will adjust the analysis to understand these temporaries better, to make ambiguously live variables fairly rare. Once ambiguously live variables are rare enough, another CL will introduce code at the beginning of a function to zero those slots on the stack. At that point the garbage collector and the stack copying routines will be able to depend on the guarantee that if a slot is marked as live in a liveness bitmap, it is initialized. R=khr CC=golang-codereviews, iant https://golang.org/cl/51810043
2014-01-16 08:32:30 -07:00
// Copyright 2014 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.
// liveness tests with inlining disabled.
// see also live2.go.
cmd/gc: handle non-escaping address-taken variables better This CL makes the bitmaps a little more precise about variables that have their address taken but for which the address does not escape to the heap, so that the variables are kept in the stack frame rather than allocated on the heap. The code before this CL handled these variables by treating every return statement as using every such variable and depending on liveness analysis to essentially treat the variable as live during the entire function. That approach has false positives and (worse) false negatives. That is, it's both sloppy and buggy: func f(b1, b2 bool) { // x live here! (sloppy) if b2 { print(0) // x live here! (sloppy) return } var z **int x := new(int) *x = 42 z = &x print(**z) // x live here (conservative) if b2 { print(1) // x live here (conservative) return } for { print(**z) // x not live here (buggy) } } The first two liveness annotations (marked sloppy) are clearly wrong: x cannot be live if it has not yet been declared. The last liveness annotation (marked buggy) is also wrong: x is live here as *z, but because there is no return statement reachable from this point in the code, the analysis treats x as dead. This CL changes the liveness calculation to mark such variables live exactly at points in the code reachable from the variable declaration. This keeps the conservative decisions but fixes the sloppy and buggy ones. The CL also detects ambiguously live variables, those that are being marked live but may not actually have been initialized, such as in this example: func f(b1 bool) { var z **int if b1 { x := new(int) *x = 42 z = &x } else { y := new(int) *y = 54 z = &y } print(**z) // x, y live here (conservative) } Since the print statement is reachable from the declaration of x, x must conservatively be marked live. The same goes for y. Although both x and y are marked live at the print statement, clearly only one of them has been initialized. They are both "ambiguously live". These ambiguously live variables cause problems for garbage collection: the collector cannot ignore them but also cannot depend on them to be initialized to valid pointer values. Ambiguously live variables do not come up too often in real code, but recent changes to the way map and interface runtime functions are invoked has created a large number of ambiguously live compiler-generated temporary variables. The next CL will adjust the analysis to understand these temporaries better, to make ambiguously live variables fairly rare. Once ambiguously live variables are rare enough, another CL will introduce code at the beginning of a function to zero those slots on the stack. At that point the garbage collector and the stack copying routines will be able to depend on the guarantee that if a slot is marked as live in a liveness bitmap, it is initialized. R=khr CC=golang-codereviews, iant https://golang.org/cl/51810043
2014-01-16 08:32:30 -07:00
package main
func printnl()
//go:noescape
func printpointer(**int)
//go:noescape
func printintpointer(*int)
//go:noescape
func printstringpointer(*string)
//go:noescape
func printstring(string)
//go:noescape
func printbytepointer(*byte)
func printint(int)
cmd/gc: handle non-escaping address-taken variables better This CL makes the bitmaps a little more precise about variables that have their address taken but for which the address does not escape to the heap, so that the variables are kept in the stack frame rather than allocated on the heap. The code before this CL handled these variables by treating every return statement as using every such variable and depending on liveness analysis to essentially treat the variable as live during the entire function. That approach has false positives and (worse) false negatives. That is, it's both sloppy and buggy: func f(b1, b2 bool) { // x live here! (sloppy) if b2 { print(0) // x live here! (sloppy) return } var z **int x := new(int) *x = 42 z = &x print(**z) // x live here (conservative) if b2 { print(1) // x live here (conservative) return } for { print(**z) // x not live here (buggy) } } The first two liveness annotations (marked sloppy) are clearly wrong: x cannot be live if it has not yet been declared. The last liveness annotation (marked buggy) is also wrong: x is live here as *z, but because there is no return statement reachable from this point in the code, the analysis treats x as dead. This CL changes the liveness calculation to mark such variables live exactly at points in the code reachable from the variable declaration. This keeps the conservative decisions but fixes the sloppy and buggy ones. The CL also detects ambiguously live variables, those that are being marked live but may not actually have been initialized, such as in this example: func f(b1 bool) { var z **int if b1 { x := new(int) *x = 42 z = &x } else { y := new(int) *y = 54 z = &y } print(**z) // x, y live here (conservative) } Since the print statement is reachable from the declaration of x, x must conservatively be marked live. The same goes for y. Although both x and y are marked live at the print statement, clearly only one of them has been initialized. They are both "ambiguously live". These ambiguously live variables cause problems for garbage collection: the collector cannot ignore them but also cannot depend on them to be initialized to valid pointer values. Ambiguously live variables do not come up too often in real code, but recent changes to the way map and interface runtime functions are invoked has created a large number of ambiguously live compiler-generated temporary variables. The next CL will adjust the analysis to understand these temporaries better, to make ambiguously live variables fairly rare. Once ambiguously live variables are rare enough, another CL will introduce code at the beginning of a function to zero those slots on the stack. At that point the garbage collector and the stack copying routines will be able to depend on the guarantee that if a slot is marked as live in a liveness bitmap, it is initialized. R=khr CC=golang-codereviews, iant https://golang.org/cl/51810043
2014-01-16 08:32:30 -07:00
func f1() {
var x *int
printpointer(&x) // ERROR "live at call to printpointer: x$"
printpointer(&x) // ERROR "live at call to printpointer: x$"
cmd/gc: handle non-escaping address-taken variables better This CL makes the bitmaps a little more precise about variables that have their address taken but for which the address does not escape to the heap, so that the variables are kept in the stack frame rather than allocated on the heap. The code before this CL handled these variables by treating every return statement as using every such variable and depending on liveness analysis to essentially treat the variable as live during the entire function. That approach has false positives and (worse) false negatives. That is, it's both sloppy and buggy: func f(b1, b2 bool) { // x live here! (sloppy) if b2 { print(0) // x live here! (sloppy) return } var z **int x := new(int) *x = 42 z = &x print(**z) // x live here (conservative) if b2 { print(1) // x live here (conservative) return } for { print(**z) // x not live here (buggy) } } The first two liveness annotations (marked sloppy) are clearly wrong: x cannot be live if it has not yet been declared. The last liveness annotation (marked buggy) is also wrong: x is live here as *z, but because there is no return statement reachable from this point in the code, the analysis treats x as dead. This CL changes the liveness calculation to mark such variables live exactly at points in the code reachable from the variable declaration. This keeps the conservative decisions but fixes the sloppy and buggy ones. The CL also detects ambiguously live variables, those that are being marked live but may not actually have been initialized, such as in this example: func f(b1 bool) { var z **int if b1 { x := new(int) *x = 42 z = &x } else { y := new(int) *y = 54 z = &y } print(**z) // x, y live here (conservative) } Since the print statement is reachable from the declaration of x, x must conservatively be marked live. The same goes for y. Although both x and y are marked live at the print statement, clearly only one of them has been initialized. They are both "ambiguously live". These ambiguously live variables cause problems for garbage collection: the collector cannot ignore them but also cannot depend on them to be initialized to valid pointer values. Ambiguously live variables do not come up too often in real code, but recent changes to the way map and interface runtime functions are invoked has created a large number of ambiguously live compiler-generated temporary variables. The next CL will adjust the analysis to understand these temporaries better, to make ambiguously live variables fairly rare. Once ambiguously live variables are rare enough, another CL will introduce code at the beginning of a function to zero those slots on the stack. At that point the garbage collector and the stack copying routines will be able to depend on the guarantee that if a slot is marked as live in a liveness bitmap, it is initialized. R=khr CC=golang-codereviews, iant https://golang.org/cl/51810043
2014-01-16 08:32:30 -07:00
}
func f2(b bool) {
if b {
printint(0) // nothing live here
cmd/gc: handle non-escaping address-taken variables better This CL makes the bitmaps a little more precise about variables that have their address taken but for which the address does not escape to the heap, so that the variables are kept in the stack frame rather than allocated on the heap. The code before this CL handled these variables by treating every return statement as using every such variable and depending on liveness analysis to essentially treat the variable as live during the entire function. That approach has false positives and (worse) false negatives. That is, it's both sloppy and buggy: func f(b1, b2 bool) { // x live here! (sloppy) if b2 { print(0) // x live here! (sloppy) return } var z **int x := new(int) *x = 42 z = &x print(**z) // x live here (conservative) if b2 { print(1) // x live here (conservative) return } for { print(**z) // x not live here (buggy) } } The first two liveness annotations (marked sloppy) are clearly wrong: x cannot be live if it has not yet been declared. The last liveness annotation (marked buggy) is also wrong: x is live here as *z, but because there is no return statement reachable from this point in the code, the analysis treats x as dead. This CL changes the liveness calculation to mark such variables live exactly at points in the code reachable from the variable declaration. This keeps the conservative decisions but fixes the sloppy and buggy ones. The CL also detects ambiguously live variables, those that are being marked live but may not actually have been initialized, such as in this example: func f(b1 bool) { var z **int if b1 { x := new(int) *x = 42 z = &x } else { y := new(int) *y = 54 z = &y } print(**z) // x, y live here (conservative) } Since the print statement is reachable from the declaration of x, x must conservatively be marked live. The same goes for y. Although both x and y are marked live at the print statement, clearly only one of them has been initialized. They are both "ambiguously live". These ambiguously live variables cause problems for garbage collection: the collector cannot ignore them but also cannot depend on them to be initialized to valid pointer values. Ambiguously live variables do not come up too often in real code, but recent changes to the way map and interface runtime functions are invoked has created a large number of ambiguously live compiler-generated temporary variables. The next CL will adjust the analysis to understand these temporaries better, to make ambiguously live variables fairly rare. Once ambiguously live variables are rare enough, another CL will introduce code at the beginning of a function to zero those slots on the stack. At that point the garbage collector and the stack copying routines will be able to depend on the guarantee that if a slot is marked as live in a liveness bitmap, it is initialized. R=khr CC=golang-codereviews, iant https://golang.org/cl/51810043
2014-01-16 08:32:30 -07:00
return
}
var x *int
printpointer(&x) // ERROR "live at call to printpointer: x$"
printpointer(&x) // ERROR "live at call to printpointer: x$"
cmd/gc: handle non-escaping address-taken variables better This CL makes the bitmaps a little more precise about variables that have their address taken but for which the address does not escape to the heap, so that the variables are kept in the stack frame rather than allocated on the heap. The code before this CL handled these variables by treating every return statement as using every such variable and depending on liveness analysis to essentially treat the variable as live during the entire function. That approach has false positives and (worse) false negatives. That is, it's both sloppy and buggy: func f(b1, b2 bool) { // x live here! (sloppy) if b2 { print(0) // x live here! (sloppy) return } var z **int x := new(int) *x = 42 z = &x print(**z) // x live here (conservative) if b2 { print(1) // x live here (conservative) return } for { print(**z) // x not live here (buggy) } } The first two liveness annotations (marked sloppy) are clearly wrong: x cannot be live if it has not yet been declared. The last liveness annotation (marked buggy) is also wrong: x is live here as *z, but because there is no return statement reachable from this point in the code, the analysis treats x as dead. This CL changes the liveness calculation to mark such variables live exactly at points in the code reachable from the variable declaration. This keeps the conservative decisions but fixes the sloppy and buggy ones. The CL also detects ambiguously live variables, those that are being marked live but may not actually have been initialized, such as in this example: func f(b1 bool) { var z **int if b1 { x := new(int) *x = 42 z = &x } else { y := new(int) *y = 54 z = &y } print(**z) // x, y live here (conservative) } Since the print statement is reachable from the declaration of x, x must conservatively be marked live. The same goes for y. Although both x and y are marked live at the print statement, clearly only one of them has been initialized. They are both "ambiguously live". These ambiguously live variables cause problems for garbage collection: the collector cannot ignore them but also cannot depend on them to be initialized to valid pointer values. Ambiguously live variables do not come up too often in real code, but recent changes to the way map and interface runtime functions are invoked has created a large number of ambiguously live compiler-generated temporary variables. The next CL will adjust the analysis to understand these temporaries better, to make ambiguously live variables fairly rare. Once ambiguously live variables are rare enough, another CL will introduce code at the beginning of a function to zero those slots on the stack. At that point the garbage collector and the stack copying routines will be able to depend on the guarantee that if a slot is marked as live in a liveness bitmap, it is initialized. R=khr CC=golang-codereviews, iant https://golang.org/cl/51810043
2014-01-16 08:32:30 -07:00
}
func f3(b bool) {
cmd/gc, runtime: make GODEBUG=gcdead=1 mode work with liveness Trying to make GODEBUG=gcdead=1 work with liveness and in particular ambiguously live variables. 1. In the liveness computation, mark all ambiguously live variables as live for the entire function, except the entry. They are zeroed directly after entry, and we need them not to be poisoned thereafter. 2. In the liveness computation, compute liveness (and deadness) for all parameters, not just pointer-containing parameters. Otherwise gcdead poisons untracked scalar parameters and results. 3. Fix liveness debugging print for -live=2 to use correct bitmaps. (Was not updated for compaction during compaction CL.) 4. Correct varkill during map literal initialization. Was killing the map itself instead of the inserted value temp. 5. Disable aggressive varkill cleanup for call arguments if the call appears in a defer or go statement. 6. In the garbage collector, avoid bug scanning empty strings. An empty string is two zeros. The multiword code only looked at the first zero and then interpreted the next two bits in the bitmap as an ordinary word bitmap. For a string the bits are 11 00, so if a live string was zero length with a 0 base pointer, the poisoning code treated the length as an ordinary word with code 00, meaning it needed poisoning, turning the string into a poison-length string with base pointer 0. By the same logic I believe that a live nil slice (bits 11 01 00) will have its cap poisoned. Always scan full multiword struct. 7. In the runtime, treat both poison words (PoisonGC and PoisonStack) as invalid pointers that warrant crashes. Manual testing as follows: - Create a script called gcdead on your PATH containing: #!/bin/bash GODEBUG=gcdead=1 GOGC=10 GOTRACEBACK=2 exec "$@" - Now you can build a test and then run 'gcdead ./foo.test'. - More importantly, you can run 'go test -short -exec gcdead std' to run all the tests. Fixes #7676. While here, enable the precise scanning of slices, since that was disabled due to bugs like these. That now works, both with and without gcdead. Fixes #7549. LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83410044
2014-04-03 18:33:25 -06:00
// Because x and y are ambiguously live, they appear
// live throughout the function, to avoid being poisoned
// in GODEBUG=gcdead=1 mode.
printint(0) // ERROR "live at call to printint: x y$"
cmd/gc: handle non-escaping address-taken variables better This CL makes the bitmaps a little more precise about variables that have their address taken but for which the address does not escape to the heap, so that the variables are kept in the stack frame rather than allocated on the heap. The code before this CL handled these variables by treating every return statement as using every such variable and depending on liveness analysis to essentially treat the variable as live during the entire function. That approach has false positives and (worse) false negatives. That is, it's both sloppy and buggy: func f(b1, b2 bool) { // x live here! (sloppy) if b2 { print(0) // x live here! (sloppy) return } var z **int x := new(int) *x = 42 z = &x print(**z) // x live here (conservative) if b2 { print(1) // x live here (conservative) return } for { print(**z) // x not live here (buggy) } } The first two liveness annotations (marked sloppy) are clearly wrong: x cannot be live if it has not yet been declared. The last liveness annotation (marked buggy) is also wrong: x is live here as *z, but because there is no return statement reachable from this point in the code, the analysis treats x as dead. This CL changes the liveness calculation to mark such variables live exactly at points in the code reachable from the variable declaration. This keeps the conservative decisions but fixes the sloppy and buggy ones. The CL also detects ambiguously live variables, those that are being marked live but may not actually have been initialized, such as in this example: func f(b1 bool) { var z **int if b1 { x := new(int) *x = 42 z = &x } else { y := new(int) *y = 54 z = &y } print(**z) // x, y live here (conservative) } Since the print statement is reachable from the declaration of x, x must conservatively be marked live. The same goes for y. Although both x and y are marked live at the print statement, clearly only one of them has been initialized. They are both "ambiguously live". These ambiguously live variables cause problems for garbage collection: the collector cannot ignore them but also cannot depend on them to be initialized to valid pointer values. Ambiguously live variables do not come up too often in real code, but recent changes to the way map and interface runtime functions are invoked has created a large number of ambiguously live compiler-generated temporary variables. The next CL will adjust the analysis to understand these temporaries better, to make ambiguously live variables fairly rare. Once ambiguously live variables are rare enough, another CL will introduce code at the beginning of a function to zero those slots on the stack. At that point the garbage collector and the stack copying routines will be able to depend on the guarantee that if a slot is marked as live in a liveness bitmap, it is initialized. R=khr CC=golang-codereviews, iant https://golang.org/cl/51810043
2014-01-16 08:32:30 -07:00
if b == false {
printint(0) // ERROR "live at call to printint: x y$"
cmd/gc: handle non-escaping address-taken variables better This CL makes the bitmaps a little more precise about variables that have their address taken but for which the address does not escape to the heap, so that the variables are kept in the stack frame rather than allocated on the heap. The code before this CL handled these variables by treating every return statement as using every such variable and depending on liveness analysis to essentially treat the variable as live during the entire function. That approach has false positives and (worse) false negatives. That is, it's both sloppy and buggy: func f(b1, b2 bool) { // x live here! (sloppy) if b2 { print(0) // x live here! (sloppy) return } var z **int x := new(int) *x = 42 z = &x print(**z) // x live here (conservative) if b2 { print(1) // x live here (conservative) return } for { print(**z) // x not live here (buggy) } } The first two liveness annotations (marked sloppy) are clearly wrong: x cannot be live if it has not yet been declared. The last liveness annotation (marked buggy) is also wrong: x is live here as *z, but because there is no return statement reachable from this point in the code, the analysis treats x as dead. This CL changes the liveness calculation to mark such variables live exactly at points in the code reachable from the variable declaration. This keeps the conservative decisions but fixes the sloppy and buggy ones. The CL also detects ambiguously live variables, those that are being marked live but may not actually have been initialized, such as in this example: func f(b1 bool) { var z **int if b1 { x := new(int) *x = 42 z = &x } else { y := new(int) *y = 54 z = &y } print(**z) // x, y live here (conservative) } Since the print statement is reachable from the declaration of x, x must conservatively be marked live. The same goes for y. Although both x and y are marked live at the print statement, clearly only one of them has been initialized. They are both "ambiguously live". These ambiguously live variables cause problems for garbage collection: the collector cannot ignore them but also cannot depend on them to be initialized to valid pointer values. Ambiguously live variables do not come up too often in real code, but recent changes to the way map and interface runtime functions are invoked has created a large number of ambiguously live compiler-generated temporary variables. The next CL will adjust the analysis to understand these temporaries better, to make ambiguously live variables fairly rare. Once ambiguously live variables are rare enough, another CL will introduce code at the beginning of a function to zero those slots on the stack. At that point the garbage collector and the stack copying routines will be able to depend on the guarantee that if a slot is marked as live in a liveness bitmap, it is initialized. R=khr CC=golang-codereviews, iant https://golang.org/cl/51810043
2014-01-16 08:32:30 -07:00
return
}
if b {
var x *int
printpointer(&x) // ERROR "live at call to printpointer: x y$"
printpointer(&x) // ERROR "live at call to printpointer: x y$"
cmd/gc: handle non-escaping address-taken variables better This CL makes the bitmaps a little more precise about variables that have their address taken but for which the address does not escape to the heap, so that the variables are kept in the stack frame rather than allocated on the heap. The code before this CL handled these variables by treating every return statement as using every such variable and depending on liveness analysis to essentially treat the variable as live during the entire function. That approach has false positives and (worse) false negatives. That is, it's both sloppy and buggy: func f(b1, b2 bool) { // x live here! (sloppy) if b2 { print(0) // x live here! (sloppy) return } var z **int x := new(int) *x = 42 z = &x print(**z) // x live here (conservative) if b2 { print(1) // x live here (conservative) return } for { print(**z) // x not live here (buggy) } } The first two liveness annotations (marked sloppy) are clearly wrong: x cannot be live if it has not yet been declared. The last liveness annotation (marked buggy) is also wrong: x is live here as *z, but because there is no return statement reachable from this point in the code, the analysis treats x as dead. This CL changes the liveness calculation to mark such variables live exactly at points in the code reachable from the variable declaration. This keeps the conservative decisions but fixes the sloppy and buggy ones. The CL also detects ambiguously live variables, those that are being marked live but may not actually have been initialized, such as in this example: func f(b1 bool) { var z **int if b1 { x := new(int) *x = 42 z = &x } else { y := new(int) *y = 54 z = &y } print(**z) // x, y live here (conservative) } Since the print statement is reachable from the declaration of x, x must conservatively be marked live. The same goes for y. Although both x and y are marked live at the print statement, clearly only one of them has been initialized. They are both "ambiguously live". These ambiguously live variables cause problems for garbage collection: the collector cannot ignore them but also cannot depend on them to be initialized to valid pointer values. Ambiguously live variables do not come up too often in real code, but recent changes to the way map and interface runtime functions are invoked has created a large number of ambiguously live compiler-generated temporary variables. The next CL will adjust the analysis to understand these temporaries better, to make ambiguously live variables fairly rare. Once ambiguously live variables are rare enough, another CL will introduce code at the beginning of a function to zero those slots on the stack. At that point the garbage collector and the stack copying routines will be able to depend on the guarantee that if a slot is marked as live in a liveness bitmap, it is initialized. R=khr CC=golang-codereviews, iant https://golang.org/cl/51810043
2014-01-16 08:32:30 -07:00
} else {
var y *int
printpointer(&y) // ERROR "live at call to printpointer: x y$"
printpointer(&y) // ERROR "live at call to printpointer: x y$"
cmd/gc: handle non-escaping address-taken variables better This CL makes the bitmaps a little more precise about variables that have their address taken but for which the address does not escape to the heap, so that the variables are kept in the stack frame rather than allocated on the heap. The code before this CL handled these variables by treating every return statement as using every such variable and depending on liveness analysis to essentially treat the variable as live during the entire function. That approach has false positives and (worse) false negatives. That is, it's both sloppy and buggy: func f(b1, b2 bool) { // x live here! (sloppy) if b2 { print(0) // x live here! (sloppy) return } var z **int x := new(int) *x = 42 z = &x print(**z) // x live here (conservative) if b2 { print(1) // x live here (conservative) return } for { print(**z) // x not live here (buggy) } } The first two liveness annotations (marked sloppy) are clearly wrong: x cannot be live if it has not yet been declared. The last liveness annotation (marked buggy) is also wrong: x is live here as *z, but because there is no return statement reachable from this point in the code, the analysis treats x as dead. This CL changes the liveness calculation to mark such variables live exactly at points in the code reachable from the variable declaration. This keeps the conservative decisions but fixes the sloppy and buggy ones. The CL also detects ambiguously live variables, those that are being marked live but may not actually have been initialized, such as in this example: func f(b1 bool) { var z **int if b1 { x := new(int) *x = 42 z = &x } else { y := new(int) *y = 54 z = &y } print(**z) // x, y live here (conservative) } Since the print statement is reachable from the declaration of x, x must conservatively be marked live. The same goes for y. Although both x and y are marked live at the print statement, clearly only one of them has been initialized. They are both "ambiguously live". These ambiguously live variables cause problems for garbage collection: the collector cannot ignore them but also cannot depend on them to be initialized to valid pointer values. Ambiguously live variables do not come up too often in real code, but recent changes to the way map and interface runtime functions are invoked has created a large number of ambiguously live compiler-generated temporary variables. The next CL will adjust the analysis to understand these temporaries better, to make ambiguously live variables fairly rare. Once ambiguously live variables are rare enough, another CL will introduce code at the beginning of a function to zero those slots on the stack. At that point the garbage collector and the stack copying routines will be able to depend on the guarantee that if a slot is marked as live in a liveness bitmap, it is initialized. R=khr CC=golang-codereviews, iant https://golang.org/cl/51810043
2014-01-16 08:32:30 -07:00
}
printint(0) // ERROR "f3: x \(type \*int\) is ambiguously live$" "f3: y \(type \*int\) is ambiguously live$" "live at call to printint: x y$"
cmd/gc: handle non-escaping address-taken variables better This CL makes the bitmaps a little more precise about variables that have their address taken but for which the address does not escape to the heap, so that the variables are kept in the stack frame rather than allocated on the heap. The code before this CL handled these variables by treating every return statement as using every such variable and depending on liveness analysis to essentially treat the variable as live during the entire function. That approach has false positives and (worse) false negatives. That is, it's both sloppy and buggy: func f(b1, b2 bool) { // x live here! (sloppy) if b2 { print(0) // x live here! (sloppy) return } var z **int x := new(int) *x = 42 z = &x print(**z) // x live here (conservative) if b2 { print(1) // x live here (conservative) return } for { print(**z) // x not live here (buggy) } } The first two liveness annotations (marked sloppy) are clearly wrong: x cannot be live if it has not yet been declared. The last liveness annotation (marked buggy) is also wrong: x is live here as *z, but because there is no return statement reachable from this point in the code, the analysis treats x as dead. This CL changes the liveness calculation to mark such variables live exactly at points in the code reachable from the variable declaration. This keeps the conservative decisions but fixes the sloppy and buggy ones. The CL also detects ambiguously live variables, those that are being marked live but may not actually have been initialized, such as in this example: func f(b1 bool) { var z **int if b1 { x := new(int) *x = 42 z = &x } else { y := new(int) *y = 54 z = &y } print(**z) // x, y live here (conservative) } Since the print statement is reachable from the declaration of x, x must conservatively be marked live. The same goes for y. Although both x and y are marked live at the print statement, clearly only one of them has been initialized. They are both "ambiguously live". These ambiguously live variables cause problems for garbage collection: the collector cannot ignore them but also cannot depend on them to be initialized to valid pointer values. Ambiguously live variables do not come up too often in real code, but recent changes to the way map and interface runtime functions are invoked has created a large number of ambiguously live compiler-generated temporary variables. The next CL will adjust the analysis to understand these temporaries better, to make ambiguously live variables fairly rare. Once ambiguously live variables are rare enough, another CL will introduce code at the beginning of a function to zero those slots on the stack. At that point the garbage collector and the stack copying routines will be able to depend on the guarantee that if a slot is marked as live in a liveness bitmap, it is initialized. R=khr CC=golang-codereviews, iant https://golang.org/cl/51810043
2014-01-16 08:32:30 -07:00
}
// The old algorithm treated x as live on all code that
// could flow to a return statement, so it included the
// function entry and code above the declaration of x
// but would not include an indirect use of x in an infinite loop.
// Check that these cases are handled correctly.
func f4(b1, b2 bool) { // x not live here
if b2 {
printint(0) // x not live here
cmd/gc: handle non-escaping address-taken variables better This CL makes the bitmaps a little more precise about variables that have their address taken but for which the address does not escape to the heap, so that the variables are kept in the stack frame rather than allocated on the heap. The code before this CL handled these variables by treating every return statement as using every such variable and depending on liveness analysis to essentially treat the variable as live during the entire function. That approach has false positives and (worse) false negatives. That is, it's both sloppy and buggy: func f(b1, b2 bool) { // x live here! (sloppy) if b2 { print(0) // x live here! (sloppy) return } var z **int x := new(int) *x = 42 z = &x print(**z) // x live here (conservative) if b2 { print(1) // x live here (conservative) return } for { print(**z) // x not live here (buggy) } } The first two liveness annotations (marked sloppy) are clearly wrong: x cannot be live if it has not yet been declared. The last liveness annotation (marked buggy) is also wrong: x is live here as *z, but because there is no return statement reachable from this point in the code, the analysis treats x as dead. This CL changes the liveness calculation to mark such variables live exactly at points in the code reachable from the variable declaration. This keeps the conservative decisions but fixes the sloppy and buggy ones. The CL also detects ambiguously live variables, those that are being marked live but may not actually have been initialized, such as in this example: func f(b1 bool) { var z **int if b1 { x := new(int) *x = 42 z = &x } else { y := new(int) *y = 54 z = &y } print(**z) // x, y live here (conservative) } Since the print statement is reachable from the declaration of x, x must conservatively be marked live. The same goes for y. Although both x and y are marked live at the print statement, clearly only one of them has been initialized. They are both "ambiguously live". These ambiguously live variables cause problems for garbage collection: the collector cannot ignore them but also cannot depend on them to be initialized to valid pointer values. Ambiguously live variables do not come up too often in real code, but recent changes to the way map and interface runtime functions are invoked has created a large number of ambiguously live compiler-generated temporary variables. The next CL will adjust the analysis to understand these temporaries better, to make ambiguously live variables fairly rare. Once ambiguously live variables are rare enough, another CL will introduce code at the beginning of a function to zero those slots on the stack. At that point the garbage collector and the stack copying routines will be able to depend on the guarantee that if a slot is marked as live in a liveness bitmap, it is initialized. R=khr CC=golang-codereviews, iant https://golang.org/cl/51810043
2014-01-16 08:32:30 -07:00
return
}
var z **int
x := new(int)
*x = 42
z = &x
printint(**z) // ERROR "live at call to printint: x z$"
cmd/gc: handle non-escaping address-taken variables better This CL makes the bitmaps a little more precise about variables that have their address taken but for which the address does not escape to the heap, so that the variables are kept in the stack frame rather than allocated on the heap. The code before this CL handled these variables by treating every return statement as using every such variable and depending on liveness analysis to essentially treat the variable as live during the entire function. That approach has false positives and (worse) false negatives. That is, it's both sloppy and buggy: func f(b1, b2 bool) { // x live here! (sloppy) if b2 { print(0) // x live here! (sloppy) return } var z **int x := new(int) *x = 42 z = &x print(**z) // x live here (conservative) if b2 { print(1) // x live here (conservative) return } for { print(**z) // x not live here (buggy) } } The first two liveness annotations (marked sloppy) are clearly wrong: x cannot be live if it has not yet been declared. The last liveness annotation (marked buggy) is also wrong: x is live here as *z, but because there is no return statement reachable from this point in the code, the analysis treats x as dead. This CL changes the liveness calculation to mark such variables live exactly at points in the code reachable from the variable declaration. This keeps the conservative decisions but fixes the sloppy and buggy ones. The CL also detects ambiguously live variables, those that are being marked live but may not actually have been initialized, such as in this example: func f(b1 bool) { var z **int if b1 { x := new(int) *x = 42 z = &x } else { y := new(int) *y = 54 z = &y } print(**z) // x, y live here (conservative) } Since the print statement is reachable from the declaration of x, x must conservatively be marked live. The same goes for y. Although both x and y are marked live at the print statement, clearly only one of them has been initialized. They are both "ambiguously live". These ambiguously live variables cause problems for garbage collection: the collector cannot ignore them but also cannot depend on them to be initialized to valid pointer values. Ambiguously live variables do not come up too often in real code, but recent changes to the way map and interface runtime functions are invoked has created a large number of ambiguously live compiler-generated temporary variables. The next CL will adjust the analysis to understand these temporaries better, to make ambiguously live variables fairly rare. Once ambiguously live variables are rare enough, another CL will introduce code at the beginning of a function to zero those slots on the stack. At that point the garbage collector and the stack copying routines will be able to depend on the guarantee that if a slot is marked as live in a liveness bitmap, it is initialized. R=khr CC=golang-codereviews, iant https://golang.org/cl/51810043
2014-01-16 08:32:30 -07:00
if b2 {
printint(1) // ERROR "live at call to printint: x$"
cmd/gc: handle non-escaping address-taken variables better This CL makes the bitmaps a little more precise about variables that have their address taken but for which the address does not escape to the heap, so that the variables are kept in the stack frame rather than allocated on the heap. The code before this CL handled these variables by treating every return statement as using every such variable and depending on liveness analysis to essentially treat the variable as live during the entire function. That approach has false positives and (worse) false negatives. That is, it's both sloppy and buggy: func f(b1, b2 bool) { // x live here! (sloppy) if b2 { print(0) // x live here! (sloppy) return } var z **int x := new(int) *x = 42 z = &x print(**z) // x live here (conservative) if b2 { print(1) // x live here (conservative) return } for { print(**z) // x not live here (buggy) } } The first two liveness annotations (marked sloppy) are clearly wrong: x cannot be live if it has not yet been declared. The last liveness annotation (marked buggy) is also wrong: x is live here as *z, but because there is no return statement reachable from this point in the code, the analysis treats x as dead. This CL changes the liveness calculation to mark such variables live exactly at points in the code reachable from the variable declaration. This keeps the conservative decisions but fixes the sloppy and buggy ones. The CL also detects ambiguously live variables, those that are being marked live but may not actually have been initialized, such as in this example: func f(b1 bool) { var z **int if b1 { x := new(int) *x = 42 z = &x } else { y := new(int) *y = 54 z = &y } print(**z) // x, y live here (conservative) } Since the print statement is reachable from the declaration of x, x must conservatively be marked live. The same goes for y. Although both x and y are marked live at the print statement, clearly only one of them has been initialized. They are both "ambiguously live". These ambiguously live variables cause problems for garbage collection: the collector cannot ignore them but also cannot depend on them to be initialized to valid pointer values. Ambiguously live variables do not come up too often in real code, but recent changes to the way map and interface runtime functions are invoked has created a large number of ambiguously live compiler-generated temporary variables. The next CL will adjust the analysis to understand these temporaries better, to make ambiguously live variables fairly rare. Once ambiguously live variables are rare enough, another CL will introduce code at the beginning of a function to zero those slots on the stack. At that point the garbage collector and the stack copying routines will be able to depend on the guarantee that if a slot is marked as live in a liveness bitmap, it is initialized. R=khr CC=golang-codereviews, iant https://golang.org/cl/51810043
2014-01-16 08:32:30 -07:00
return
}
for {
printint(**z) // ERROR "live at call to printint: x z$"
cmd/gc: handle non-escaping address-taken variables better This CL makes the bitmaps a little more precise about variables that have their address taken but for which the address does not escape to the heap, so that the variables are kept in the stack frame rather than allocated on the heap. The code before this CL handled these variables by treating every return statement as using every such variable and depending on liveness analysis to essentially treat the variable as live during the entire function. That approach has false positives and (worse) false negatives. That is, it's both sloppy and buggy: func f(b1, b2 bool) { // x live here! (sloppy) if b2 { print(0) // x live here! (sloppy) return } var z **int x := new(int) *x = 42 z = &x print(**z) // x live here (conservative) if b2 { print(1) // x live here (conservative) return } for { print(**z) // x not live here (buggy) } } The first two liveness annotations (marked sloppy) are clearly wrong: x cannot be live if it has not yet been declared. The last liveness annotation (marked buggy) is also wrong: x is live here as *z, but because there is no return statement reachable from this point in the code, the analysis treats x as dead. This CL changes the liveness calculation to mark such variables live exactly at points in the code reachable from the variable declaration. This keeps the conservative decisions but fixes the sloppy and buggy ones. The CL also detects ambiguously live variables, those that are being marked live but may not actually have been initialized, such as in this example: func f(b1 bool) { var z **int if b1 { x := new(int) *x = 42 z = &x } else { y := new(int) *y = 54 z = &y } print(**z) // x, y live here (conservative) } Since the print statement is reachable from the declaration of x, x must conservatively be marked live. The same goes for y. Although both x and y are marked live at the print statement, clearly only one of them has been initialized. They are both "ambiguously live". These ambiguously live variables cause problems for garbage collection: the collector cannot ignore them but also cannot depend on them to be initialized to valid pointer values. Ambiguously live variables do not come up too often in real code, but recent changes to the way map and interface runtime functions are invoked has created a large number of ambiguously live compiler-generated temporary variables. The next CL will adjust the analysis to understand these temporaries better, to make ambiguously live variables fairly rare. Once ambiguously live variables are rare enough, another CL will introduce code at the beginning of a function to zero those slots on the stack. At that point the garbage collector and the stack copying routines will be able to depend on the guarantee that if a slot is marked as live in a liveness bitmap, it is initialized. R=khr CC=golang-codereviews, iant https://golang.org/cl/51810043
2014-01-16 08:32:30 -07:00
}
}
func f5(b1 bool) {
var z **int
if b1 {
x := new(int)
*x = 42
z = &x
} else {
y := new(int)
*y = 54
z = &y
}
printint(**z) // ERROR "f5: x \(type \*int\) is ambiguously live$" "f5: y \(type \*int\) is ambiguously live$" "live at call to printint: x y$"
cmd/gc: handle non-escaping address-taken variables better This CL makes the bitmaps a little more precise about variables that have their address taken but for which the address does not escape to the heap, so that the variables are kept in the stack frame rather than allocated on the heap. The code before this CL handled these variables by treating every return statement as using every such variable and depending on liveness analysis to essentially treat the variable as live during the entire function. That approach has false positives and (worse) false negatives. That is, it's both sloppy and buggy: func f(b1, b2 bool) { // x live here! (sloppy) if b2 { print(0) // x live here! (sloppy) return } var z **int x := new(int) *x = 42 z = &x print(**z) // x live here (conservative) if b2 { print(1) // x live here (conservative) return } for { print(**z) // x not live here (buggy) } } The first two liveness annotations (marked sloppy) are clearly wrong: x cannot be live if it has not yet been declared. The last liveness annotation (marked buggy) is also wrong: x is live here as *z, but because there is no return statement reachable from this point in the code, the analysis treats x as dead. This CL changes the liveness calculation to mark such variables live exactly at points in the code reachable from the variable declaration. This keeps the conservative decisions but fixes the sloppy and buggy ones. The CL also detects ambiguously live variables, those that are being marked live but may not actually have been initialized, such as in this example: func f(b1 bool) { var z **int if b1 { x := new(int) *x = 42 z = &x } else { y := new(int) *y = 54 z = &y } print(**z) // x, y live here (conservative) } Since the print statement is reachable from the declaration of x, x must conservatively be marked live. The same goes for y. Although both x and y are marked live at the print statement, clearly only one of them has been initialized. They are both "ambiguously live". These ambiguously live variables cause problems for garbage collection: the collector cannot ignore them but also cannot depend on them to be initialized to valid pointer values. Ambiguously live variables do not come up too often in real code, but recent changes to the way map and interface runtime functions are invoked has created a large number of ambiguously live compiler-generated temporary variables. The next CL will adjust the analysis to understand these temporaries better, to make ambiguously live variables fairly rare. Once ambiguously live variables are rare enough, another CL will introduce code at the beginning of a function to zero those slots on the stack. At that point the garbage collector and the stack copying routines will be able to depend on the guarantee that if a slot is marked as live in a liveness bitmap, it is initialized. R=khr CC=golang-codereviews, iant https://golang.org/cl/51810043
2014-01-16 08:32:30 -07:00
}
// confusion about the _ result used to cause spurious "live at entry to f6: _".
func f6() (_, y string) {
y = "hello"
return
}
// confusion about addressed results used to cause "live at entry to f7: x".
func f7() (x string) {
_ = &x
x = "hello"
return
}
// ignoring block returns used to cause "live at entry to f8: x, y".
func f8() (x, y string) {
return g8()
}
func g8() (string, string)
// ignoring block assignments used to cause "live at entry to f9: x"
// issue 7205
var i9 interface{}
func f9() bool {
g8()
x := i9
return x != interface{}(99.0i) // ERROR "live at call to convT2E: x$"
}
// liveness formerly confused by UNDEF followed by RET,
// leading to "live at entry to f10: ~r1" (unnamed result).
func f10() string {
panic(1)
}
// liveness formerly confused by select, thinking runtime.selectgo
// can return to next instruction; it always jumps elsewhere.
// note that you have to use at least two cases in the select
// to get a true select; smaller selects compile to optimized helper functions.
var c chan *int
var b bool
// this used to have a spurious "live at entry to f11a: ~r0"
func f11a() *int {
select { // ERROR "live at call to newselect: autotmp_[0-9]+$" "live at call to selectgo: autotmp_[0-9]+$"
case <-c: // ERROR "live at call to selectrecv: autotmp_[0-9]+$"
return nil
case <-c: // ERROR "live at call to selectrecv: autotmp_[0-9]+$"
return nil
}
}
func f11b() *int {
p := new(int)
if b {
// At this point p is dead: the code here cannot
// get to the bottom of the function.
// This used to have a spurious "live at call to printint: p".
printint(1) // nothing live here!
select { // ERROR "live at call to newselect: autotmp_[0-9]+$" "live at call to selectgo: autotmp_[0-9]+$"
case <-c: // ERROR "live at call to selectrecv: autotmp_[0-9]+$"
return nil
case <-c: // ERROR "live at call to selectrecv: autotmp_[0-9]+$"
return nil
}
}
println(*p)
return nil
}
func f11c() *int {
p := new(int)
if b {
// Unlike previous, the cases in this select fall through,
// so we can get to the println, so p is not dead.
printint(1) // ERROR "live at call to printint: p$"
select { // ERROR "live at call to newselect: autotmp_[0-9]+ p$" "live at call to selectgo: autotmp_[0-9]+ p$"
case <-c: // ERROR "live at call to selectrecv: autotmp_[0-9]+ p$"
case <-c: // ERROR "live at call to selectrecv: autotmp_[0-9]+ p$"
}
}
println(*p)
return nil
}
// similarly, select{} does not fall through.
// this used to have a spurious "live at entry to f12: ~r0".
func f12() *int {
if b {
select {}
} else {
return nil
}
}
// incorrectly placed VARDEF annotations can cause missing liveness annotations.
// this used to be missing the fact that s is live during the call to g13 (because it is
// needed for the call to h13).
func f13() {
s := "hello"
s = h13(s, g13(s)) // ERROR "live at call to g13: s$"
}
func g13(string) string
func h13(string, string) string
cmd/gc: liveness-related bug fixes 1. On entry to a function, only zero the ambiguously live stack variables. Before, we were zeroing all stack variables containing pointers. The zeroing is pretty inefficient right now (issue 7624), but there are also too many stack variables detected as ambiguously live (issue 7345), and that must be addressed before deciding how to improve the zeroing code. (Changes in 5g/ggen.c, 6g/ggen.c, 8g/ggen.c, gc/pgen.c) Fixes #7647. 2. Make the regopt word-based liveness analysis preserve the whole-variable liveness property expected by the garbage collection bitmap liveness analysis. That is, if the regopt liveness decides that one word in a struct needs to be preserved, make sure it preserves the entire struct. This is particularly important for multiword values such as strings, slices, and interfaces, in which all the words need to be present in order to understand the meaning. (Changes in 5g/reg.c, 6g/reg.c, 8g/reg.c.) Fixes #7591. 3. Make the regopt word-based liveness analysis treat a variable as having its address taken - which makes it preserved across all future calls - whenever n->addrtaken is set, for consistency with the gc bitmap liveness analysis, even if there is no machine instruction actually taking the address. In this case n->addrtaken is incorrect (a nicer way to put it is overconservative), and ideally there would be no such cases, but they can happen and the two analyses need to agree. (Changes in 5g/reg.c, 6g/reg.c, 8g/reg.c; test in bug484.go.) Fixes crashes found by turning off "zero everything" in step 1. 4. Remove spurious VARDEF annotations. As the comment in gc/pgen.c explains, the VARDEF must immediately precede the initialization. It cannot be too early, and it cannot be too late. In particular, if a function call sits between the VARDEF and the actual machine instructions doing the initialization, the variable will be treated as live during that function call even though it is uninitialized, leading to problems. (Changes in gc/gen.c; test in live.go.) Fixes crashes found by turning off "zero everything" in step 1. 5. Do not treat loading the address of a wide value as a signal that the value must be initialized. Instead depend on the existence of a VARDEF or the first actual read/write of a word in the value. If the load is in order to pass the address to a function that does the actual initialization, treating the load as an implicit VARDEF causes the same problems as described in step 4. The alternative is to arrange to zero every such value before passing it to the real initialization function, but this is a much easier and more efficient change. (Changes in gc/plive.c.) Fixes crashes found by turning off "zero everything" in step 1. 6. Treat wide input parameters with their address taken as initialized on entry to the function. Otherwise they look "ambiguously live" and we will try to emit code to zero them. (Changes in gc/plive.c.) Fixes crashes found by turning off "zero everything" in step 1. 7. An array of length 0 has no pointers, even if the element type does. Without this change, the zeroing code complains when asked to clear a 0-length array. (Changes in gc/reflect.c.) LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/80160044
2014-03-27 12:05:57 -06:00
// more incorrectly placed VARDEF.
func f14() {
x := g14()
printstringpointer(&x) // ERROR "live at call to printstringpointer: x$"
cmd/gc: liveness-related bug fixes 1. On entry to a function, only zero the ambiguously live stack variables. Before, we were zeroing all stack variables containing pointers. The zeroing is pretty inefficient right now (issue 7624), but there are also too many stack variables detected as ambiguously live (issue 7345), and that must be addressed before deciding how to improve the zeroing code. (Changes in 5g/ggen.c, 6g/ggen.c, 8g/ggen.c, gc/pgen.c) Fixes #7647. 2. Make the regopt word-based liveness analysis preserve the whole-variable liveness property expected by the garbage collection bitmap liveness analysis. That is, if the regopt liveness decides that one word in a struct needs to be preserved, make sure it preserves the entire struct. This is particularly important for multiword values such as strings, slices, and interfaces, in which all the words need to be present in order to understand the meaning. (Changes in 5g/reg.c, 6g/reg.c, 8g/reg.c.) Fixes #7591. 3. Make the regopt word-based liveness analysis treat a variable as having its address taken - which makes it preserved across all future calls - whenever n->addrtaken is set, for consistency with the gc bitmap liveness analysis, even if there is no machine instruction actually taking the address. In this case n->addrtaken is incorrect (a nicer way to put it is overconservative), and ideally there would be no such cases, but they can happen and the two analyses need to agree. (Changes in 5g/reg.c, 6g/reg.c, 8g/reg.c; test in bug484.go.) Fixes crashes found by turning off "zero everything" in step 1. 4. Remove spurious VARDEF annotations. As the comment in gc/pgen.c explains, the VARDEF must immediately precede the initialization. It cannot be too early, and it cannot be too late. In particular, if a function call sits between the VARDEF and the actual machine instructions doing the initialization, the variable will be treated as live during that function call even though it is uninitialized, leading to problems. (Changes in gc/gen.c; test in live.go.) Fixes crashes found by turning off "zero everything" in step 1. 5. Do not treat loading the address of a wide value as a signal that the value must be initialized. Instead depend on the existence of a VARDEF or the first actual read/write of a word in the value. If the load is in order to pass the address to a function that does the actual initialization, treating the load as an implicit VARDEF causes the same problems as described in step 4. The alternative is to arrange to zero every such value before passing it to the real initialization function, but this is a much easier and more efficient change. (Changes in gc/plive.c.) Fixes crashes found by turning off "zero everything" in step 1. 6. Treat wide input parameters with their address taken as initialized on entry to the function. Otherwise they look "ambiguously live" and we will try to emit code to zero them. (Changes in gc/plive.c.) Fixes crashes found by turning off "zero everything" in step 1. 7. An array of length 0 has no pointers, even if the element type does. Without this change, the zeroing code complains when asked to clear a 0-length array. (Changes in gc/reflect.c.) LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/80160044
2014-03-27 12:05:57 -06:00
}
func g14() string
func f15() {
var x string
_ = &x
x = g15() // ERROR "live at call to g15: x$"
printstring(x) // ERROR "live at call to printstring: x$"
cmd/gc: liveness-related bug fixes 1. On entry to a function, only zero the ambiguously live stack variables. Before, we were zeroing all stack variables containing pointers. The zeroing is pretty inefficient right now (issue 7624), but there are also too many stack variables detected as ambiguously live (issue 7345), and that must be addressed before deciding how to improve the zeroing code. (Changes in 5g/ggen.c, 6g/ggen.c, 8g/ggen.c, gc/pgen.c) Fixes #7647. 2. Make the regopt word-based liveness analysis preserve the whole-variable liveness property expected by the garbage collection bitmap liveness analysis. That is, if the regopt liveness decides that one word in a struct needs to be preserved, make sure it preserves the entire struct. This is particularly important for multiword values such as strings, slices, and interfaces, in which all the words need to be present in order to understand the meaning. (Changes in 5g/reg.c, 6g/reg.c, 8g/reg.c.) Fixes #7591. 3. Make the regopt word-based liveness analysis treat a variable as having its address taken - which makes it preserved across all future calls - whenever n->addrtaken is set, for consistency with the gc bitmap liveness analysis, even if there is no machine instruction actually taking the address. In this case n->addrtaken is incorrect (a nicer way to put it is overconservative), and ideally there would be no such cases, but they can happen and the two analyses need to agree. (Changes in 5g/reg.c, 6g/reg.c, 8g/reg.c; test in bug484.go.) Fixes crashes found by turning off "zero everything" in step 1. 4. Remove spurious VARDEF annotations. As the comment in gc/pgen.c explains, the VARDEF must immediately precede the initialization. It cannot be too early, and it cannot be too late. In particular, if a function call sits between the VARDEF and the actual machine instructions doing the initialization, the variable will be treated as live during that function call even though it is uninitialized, leading to problems. (Changes in gc/gen.c; test in live.go.) Fixes crashes found by turning off "zero everything" in step 1. 5. Do not treat loading the address of a wide value as a signal that the value must be initialized. Instead depend on the existence of a VARDEF or the first actual read/write of a word in the value. If the load is in order to pass the address to a function that does the actual initialization, treating the load as an implicit VARDEF causes the same problems as described in step 4. The alternative is to arrange to zero every such value before passing it to the real initialization function, but this is a much easier and more efficient change. (Changes in gc/plive.c.) Fixes crashes found by turning off "zero everything" in step 1. 6. Treat wide input parameters with their address taken as initialized on entry to the function. Otherwise they look "ambiguously live" and we will try to emit code to zero them. (Changes in gc/plive.c.) Fixes crashes found by turning off "zero everything" in step 1. 7. An array of length 0 has no pointers, even if the element type does. Without this change, the zeroing code complains when asked to clear a 0-length array. (Changes in gc/reflect.c.) LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/80160044
2014-03-27 12:05:57 -06:00
}
func g15() string
cmd/gc: shorten temporary lifetimes when possible The new channel and map runtime routines take pointers to values, typically temporaries. Without help, the compiler cannot tell when those temporaries stop being needed, because it isn't sure what happened to the pointer. Arrange to insert explicit VARKILL instructions for these temporaries so that the liveness analysis can avoid seeing them as "ambiguously live". The change is made in order.c, which was already in charge of introducing temporaries to preserve the order-of-evaluation guarantees. Now its job has expanded to include introducing temporaries as needed by runtime routines, and then also inserting the VARKILL annotations for all these temporaries, so that their lifetimes can be shortened. In order to do its job for the map runtime routines, order.c arranges that all map lookups or map assignments have the form: x = m[k] x, y = m[k] m[k] = x where x, y, and k are simple variables (often temporaries). Likewise, receiving from a channel is now always: x = <-c In order to provide the map guarantee, order.c is responsible for rewriting x op= y into x = x op y, so that m[k] += z becomes t = m[k] t2 = t + z m[k] = t2 While here, fix a few bugs in order.c's traversal: it was failing to walk into select and switch case bodies, so order of evaluation guarantees were not preserved in those situations. Added tests to test/reorder2.go. Fixes #7671. In gc/popt's temporary-merging optimization, allow merging of temporaries with their address taken as long as the liveness ranges do not intersect. (There is a good chance of that now that we have VARKILL annotations to limit the liveness range.) Explicitly killing temporaries cuts the number of ambiguously live temporaries that must be zeroed in the godoc binary from 860 to 711, or -17%. There is more work to be done, but this is a good checkpoint. Update #7345 LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/81940043
2014-04-01 11:31:38 -06:00
// Checking that various temporaries do not persist or cause
// ambiguously live values that must be zeroed.
// The exact temporary names are inconsequential but we are
// trying to check that there is only one at any given site,
// and also that none show up in "ambiguously live" messages.
var m map[string]int
func f16() {
if b {
delete(m, "hi") // ERROR "live at call to mapdelete: autotmp_[0-9]+$"
}
delete(m, "hi") // ERROR "live at call to mapdelete: autotmp_[0-9]+$"
delete(m, "hi") // ERROR "live at call to mapdelete: autotmp_[0-9]+$"
}
var m2s map[string]*byte
var m2 map[[2]string]*byte
var x2 [2]string
var bp *byte
func f17a() {
// value temporary only
if b {
m2[x2] = nil // ERROR "live at call to mapassign1: autotmp_[0-9]+$"
}
m2[x2] = nil // ERROR "live at call to mapassign1: autotmp_[0-9]+$"
m2[x2] = nil // ERROR "live at call to mapassign1: autotmp_[0-9]+$"
}
func f17b() {
// key temporary only
if b {
m2s["x"] = bp // ERROR "live at call to mapassign1: autotmp_[0-9]+$"
}
m2s["x"] = bp // ERROR "live at call to mapassign1: autotmp_[0-9]+$"
m2s["x"] = bp // ERROR "live at call to mapassign1: autotmp_[0-9]+$"
}
func f17c() {
// key and value temporaries
if b {
m2s["x"] = nil // ERROR "live at call to mapassign1: autotmp_[0-9]+ autotmp_[0-9]+$"
}
m2s["x"] = nil // ERROR "live at call to mapassign1: autotmp_[0-9]+ autotmp_[0-9]+$"
m2s["x"] = nil // ERROR "live at call to mapassign1: autotmp_[0-9]+ autotmp_[0-9]+$"
}
func g18() [2]string
func f18() {
// key temporary for mapaccess.
// temporary introduced by orderexpr.
var z *byte
if b {
z = m2[g18()] // ERROR "live at call to mapaccess1: autotmp_[0-9]+$"
}
z = m2[g18()] // ERROR "live at call to mapaccess1: autotmp_[0-9]+$"
z = m2[g18()] // ERROR "live at call to mapaccess1: autotmp_[0-9]+$"
printbytepointer(z)
cmd/gc: shorten temporary lifetimes when possible The new channel and map runtime routines take pointers to values, typically temporaries. Without help, the compiler cannot tell when those temporaries stop being needed, because it isn't sure what happened to the pointer. Arrange to insert explicit VARKILL instructions for these temporaries so that the liveness analysis can avoid seeing them as "ambiguously live". The change is made in order.c, which was already in charge of introducing temporaries to preserve the order-of-evaluation guarantees. Now its job has expanded to include introducing temporaries as needed by runtime routines, and then also inserting the VARKILL annotations for all these temporaries, so that their lifetimes can be shortened. In order to do its job for the map runtime routines, order.c arranges that all map lookups or map assignments have the form: x = m[k] x, y = m[k] m[k] = x where x, y, and k are simple variables (often temporaries). Likewise, receiving from a channel is now always: x = <-c In order to provide the map guarantee, order.c is responsible for rewriting x op= y into x = x op y, so that m[k] += z becomes t = m[k] t2 = t + z m[k] = t2 While here, fix a few bugs in order.c's traversal: it was failing to walk into select and switch case bodies, so order of evaluation guarantees were not preserved in those situations. Added tests to test/reorder2.go. Fixes #7671. In gc/popt's temporary-merging optimization, allow merging of temporaries with their address taken as long as the liveness ranges do not intersect. (There is a good chance of that now that we have VARKILL annotations to limit the liveness range.) Explicitly killing temporaries cuts the number of ambiguously live temporaries that must be zeroed in the godoc binary from 860 to 711, or -17%. There is more work to be done, but this is a good checkpoint. Update #7345 LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/81940043
2014-04-01 11:31:38 -06:00
}
var ch chan *byte
func f19() {
// dest temporary for channel receive.
var z *byte
cmd/gc: shorten temporary lifetimes when possible The new channel and map runtime routines take pointers to values, typically temporaries. Without help, the compiler cannot tell when those temporaries stop being needed, because it isn't sure what happened to the pointer. Arrange to insert explicit VARKILL instructions for these temporaries so that the liveness analysis can avoid seeing them as "ambiguously live". The change is made in order.c, which was already in charge of introducing temporaries to preserve the order-of-evaluation guarantees. Now its job has expanded to include introducing temporaries as needed by runtime routines, and then also inserting the VARKILL annotations for all these temporaries, so that their lifetimes can be shortened. In order to do its job for the map runtime routines, order.c arranges that all map lookups or map assignments have the form: x = m[k] x, y = m[k] m[k] = x where x, y, and k are simple variables (often temporaries). Likewise, receiving from a channel is now always: x = <-c In order to provide the map guarantee, order.c is responsible for rewriting x op= y into x = x op y, so that m[k] += z becomes t = m[k] t2 = t + z m[k] = t2 While here, fix a few bugs in order.c's traversal: it was failing to walk into select and switch case bodies, so order of evaluation guarantees were not preserved in those situations. Added tests to test/reorder2.go. Fixes #7671. In gc/popt's temporary-merging optimization, allow merging of temporaries with their address taken as long as the liveness ranges do not intersect. (There is a good chance of that now that we have VARKILL annotations to limit the liveness range.) Explicitly killing temporaries cuts the number of ambiguously live temporaries that must be zeroed in the godoc binary from 860 to 711, or -17%. There is more work to be done, but this is a good checkpoint. Update #7345 LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/81940043
2014-04-01 11:31:38 -06:00
if b {
z = <-ch // ERROR "live at call to chanrecv1: autotmp_[0-9]+$"
}
z = <-ch // ERROR "live at call to chanrecv1: autotmp_[0-9]+$"
z = <-ch // ERROR "live at call to chanrecv1: autotmp_[0-9]+$"
printbytepointer(z)
cmd/gc: shorten temporary lifetimes when possible The new channel and map runtime routines take pointers to values, typically temporaries. Without help, the compiler cannot tell when those temporaries stop being needed, because it isn't sure what happened to the pointer. Arrange to insert explicit VARKILL instructions for these temporaries so that the liveness analysis can avoid seeing them as "ambiguously live". The change is made in order.c, which was already in charge of introducing temporaries to preserve the order-of-evaluation guarantees. Now its job has expanded to include introducing temporaries as needed by runtime routines, and then also inserting the VARKILL annotations for all these temporaries, so that their lifetimes can be shortened. In order to do its job for the map runtime routines, order.c arranges that all map lookups or map assignments have the form: x = m[k] x, y = m[k] m[k] = x where x, y, and k are simple variables (often temporaries). Likewise, receiving from a channel is now always: x = <-c In order to provide the map guarantee, order.c is responsible for rewriting x op= y into x = x op y, so that m[k] += z becomes t = m[k] t2 = t + z m[k] = t2 While here, fix a few bugs in order.c's traversal: it was failing to walk into select and switch case bodies, so order of evaluation guarantees were not preserved in those situations. Added tests to test/reorder2.go. Fixes #7671. In gc/popt's temporary-merging optimization, allow merging of temporaries with their address taken as long as the liveness ranges do not intersect. (There is a good chance of that now that we have VARKILL annotations to limit the liveness range.) Explicitly killing temporaries cuts the number of ambiguously live temporaries that must be zeroed in the godoc binary from 860 to 711, or -17%. There is more work to be done, but this is a good checkpoint. Update #7345 LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/81940043
2014-04-01 11:31:38 -06:00
}
func f20() {
// src temporary for channel send
if b {
ch <- nil // ERROR "live at call to chansend1: autotmp_[0-9]+$"
}
ch <- nil // ERROR "live at call to chansend1: autotmp_[0-9]+$"
ch <- nil // ERROR "live at call to chansend1: autotmp_[0-9]+$"
}
func f21() {
// key temporary for mapaccess using array literal key.
var z *byte
if b {
z = m2[[2]string{"x", "y"}] // ERROR "live at call to mapaccess1: autotmp_[0-9]+$"
}
z = m2[[2]string{"x", "y"}] // ERROR "live at call to mapaccess1: autotmp_[0-9]+$"
z = m2[[2]string{"x", "y"}] // ERROR "live at call to mapaccess1: autotmp_[0-9]+$"
printbytepointer(z)
cmd/gc: shorten temporary lifetimes when possible The new channel and map runtime routines take pointers to values, typically temporaries. Without help, the compiler cannot tell when those temporaries stop being needed, because it isn't sure what happened to the pointer. Arrange to insert explicit VARKILL instructions for these temporaries so that the liveness analysis can avoid seeing them as "ambiguously live". The change is made in order.c, which was already in charge of introducing temporaries to preserve the order-of-evaluation guarantees. Now its job has expanded to include introducing temporaries as needed by runtime routines, and then also inserting the VARKILL annotations for all these temporaries, so that their lifetimes can be shortened. In order to do its job for the map runtime routines, order.c arranges that all map lookups or map assignments have the form: x = m[k] x, y = m[k] m[k] = x where x, y, and k are simple variables (often temporaries). Likewise, receiving from a channel is now always: x = <-c In order to provide the map guarantee, order.c is responsible for rewriting x op= y into x = x op y, so that m[k] += z becomes t = m[k] t2 = t + z m[k] = t2 While here, fix a few bugs in order.c's traversal: it was failing to walk into select and switch case bodies, so order of evaluation guarantees were not preserved in those situations. Added tests to test/reorder2.go. Fixes #7671. In gc/popt's temporary-merging optimization, allow merging of temporaries with their address taken as long as the liveness ranges do not intersect. (There is a good chance of that now that we have VARKILL annotations to limit the liveness range.) Explicitly killing temporaries cuts the number of ambiguously live temporaries that must be zeroed in the godoc binary from 860 to 711, or -17%. There is more work to be done, but this is a good checkpoint. Update #7345 LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/81940043
2014-04-01 11:31:38 -06:00
}
func f23() {
// key temporary for two-result map access using array literal key.
var z *byte
var ok bool
if b {
z, ok = m2[[2]string{"x", "y"}] // ERROR "live at call to mapaccess2: autotmp_[0-9]+$"
}
z, ok = m2[[2]string{"x", "y"}] // ERROR "live at call to mapaccess2: autotmp_[0-9]+$"
z, ok = m2[[2]string{"x", "y"}] // ERROR "live at call to mapaccess2: autotmp_[0-9]+$"
printbytepointer(z)
print(ok)
cmd/gc: shorten temporary lifetimes when possible The new channel and map runtime routines take pointers to values, typically temporaries. Without help, the compiler cannot tell when those temporaries stop being needed, because it isn't sure what happened to the pointer. Arrange to insert explicit VARKILL instructions for these temporaries so that the liveness analysis can avoid seeing them as "ambiguously live". The change is made in order.c, which was already in charge of introducing temporaries to preserve the order-of-evaluation guarantees. Now its job has expanded to include introducing temporaries as needed by runtime routines, and then also inserting the VARKILL annotations for all these temporaries, so that their lifetimes can be shortened. In order to do its job for the map runtime routines, order.c arranges that all map lookups or map assignments have the form: x = m[k] x, y = m[k] m[k] = x where x, y, and k are simple variables (often temporaries). Likewise, receiving from a channel is now always: x = <-c In order to provide the map guarantee, order.c is responsible for rewriting x op= y into x = x op y, so that m[k] += z becomes t = m[k] t2 = t + z m[k] = t2 While here, fix a few bugs in order.c's traversal: it was failing to walk into select and switch case bodies, so order of evaluation guarantees were not preserved in those situations. Added tests to test/reorder2.go. Fixes #7671. In gc/popt's temporary-merging optimization, allow merging of temporaries with their address taken as long as the liveness ranges do not intersect. (There is a good chance of that now that we have VARKILL annotations to limit the liveness range.) Explicitly killing temporaries cuts the number of ambiguously live temporaries that must be zeroed in the godoc binary from 860 to 711, or -17%. There is more work to be done, but this is a good checkpoint. Update #7345 LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/81940043
2014-04-01 11:31:38 -06:00
}
func f24() {
// key temporary for map access using array literal key.
// value temporary too.
if b {
m2[[2]string{"x", "y"}] = nil // ERROR "live at call to mapassign1: autotmp_[0-9]+ autotmp_[0-9]+$"
}
m2[[2]string{"x", "y"}] = nil // ERROR "live at call to mapassign1: autotmp_[0-9]+ autotmp_[0-9]+$"
m2[[2]string{"x", "y"}] = nil // ERROR "live at call to mapassign1: autotmp_[0-9]+ autotmp_[0-9]+$"
}
cmd/gc: shorten more temporary lifetimes 1. In functions with heap-allocated result variables or with defer statements, the return sequence requires more than just a single RET instruction. There is an optimization that arranges for all returns to jump to a single copy of the return epilogue in this case. Unfortunately, that optimization is fundamentally incompatible with PC-based liveness information: it takes PCs at many different points in the function and makes them all land at one PC, making the combined liveness information at that target PC a mess. Disable this optimization, so that each return site gets its own copy of the 'call deferreturn' and the copying of result variables back from the heap. This removes quite a few spurious 'ambiguously live' variables. 2. Let orderexpr allocate temporaries that are passed by address to a function call and then die on return, so that we can arrange an appropriate VARKILL. 2a. Do this for ... slices. 2b. Do this for closure structs. 2c. Do this for runtime.concatstring, which is the implementation of large string additions. Change representation of OADDSTR to an explicit list in typecheck to avoid reconstructing list in both walk and order. 3. Let orderexpr allocate the temporary variable copies used for range loops, so that they can be killed when the loop is over. Similarly, let it allocate the temporary holding the map iterator. CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. This CL reduces the number to 121. Still more to do, but another good checkpoint. Update #7345 LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83090046
2014-04-01 18:02:54 -06:00
// defer should not cause spurious ambiguously live variables
func f25(b bool) {
defer g25()
if b {
return
}
var x string
_ = &x
x = g15() // ERROR "live at call to g15: x$"
printstring(x) // ERROR "live at call to printstring: x$"
} // ERROR "live at call to deferreturn: x$"
cmd/gc: shorten more temporary lifetimes 1. In functions with heap-allocated result variables or with defer statements, the return sequence requires more than just a single RET instruction. There is an optimization that arranges for all returns to jump to a single copy of the return epilogue in this case. Unfortunately, that optimization is fundamentally incompatible with PC-based liveness information: it takes PCs at many different points in the function and makes them all land at one PC, making the combined liveness information at that target PC a mess. Disable this optimization, so that each return site gets its own copy of the 'call deferreturn' and the copying of result variables back from the heap. This removes quite a few spurious 'ambiguously live' variables. 2. Let orderexpr allocate temporaries that are passed by address to a function call and then die on return, so that we can arrange an appropriate VARKILL. 2a. Do this for ... slices. 2b. Do this for closure structs. 2c. Do this for runtime.concatstring, which is the implementation of large string additions. Change representation of OADDSTR to an explicit list in typecheck to avoid reconstructing list in both walk and order. 3. Let orderexpr allocate the temporary variable copies used for range loops, so that they can be killed when the loop is over. Similarly, let it allocate the temporary holding the map iterator. CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. This CL reduces the number to 121. Still more to do, but another good checkpoint. Update #7345 LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83090046
2014-04-01 18:02:54 -06:00
func g25()
cmd/gc: shorten more temporary lifetimes 1. In functions with heap-allocated result variables or with defer statements, the return sequence requires more than just a single RET instruction. There is an optimization that arranges for all returns to jump to a single copy of the return epilogue in this case. Unfortunately, that optimization is fundamentally incompatible with PC-based liveness information: it takes PCs at many different points in the function and makes them all land at one PC, making the combined liveness information at that target PC a mess. Disable this optimization, so that each return site gets its own copy of the 'call deferreturn' and the copying of result variables back from the heap. This removes quite a few spurious 'ambiguously live' variables. 2. Let orderexpr allocate temporaries that are passed by address to a function call and then die on return, so that we can arrange an appropriate VARKILL. 2a. Do this for ... slices. 2b. Do this for closure structs. 2c. Do this for runtime.concatstring, which is the implementation of large string additions. Change representation of OADDSTR to an explicit list in typecheck to avoid reconstructing list in both walk and order. 3. Let orderexpr allocate the temporary variable copies used for range loops, so that they can be killed when the loop is over. Similarly, let it allocate the temporary holding the map iterator. CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. This CL reduces the number to 121. Still more to do, but another good checkpoint. Update #7345 LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83090046
2014-04-01 18:02:54 -06:00
// non-escaping ... slices passed to function call should die on return,
// so that the temporaries do not stack and do not cause ambiguously
// live variables.
func f26(b bool) {
if b {
print26((*int)(nil), (*int)(nil), (*int)(nil)) // ERROR "live at call to print26: autotmp_[0-9]+$"
cmd/gc: shorten more temporary lifetimes 1. In functions with heap-allocated result variables or with defer statements, the return sequence requires more than just a single RET instruction. There is an optimization that arranges for all returns to jump to a single copy of the return epilogue in this case. Unfortunately, that optimization is fundamentally incompatible with PC-based liveness information: it takes PCs at many different points in the function and makes them all land at one PC, making the combined liveness information at that target PC a mess. Disable this optimization, so that each return site gets its own copy of the 'call deferreturn' and the copying of result variables back from the heap. This removes quite a few spurious 'ambiguously live' variables. 2. Let orderexpr allocate temporaries that are passed by address to a function call and then die on return, so that we can arrange an appropriate VARKILL. 2a. Do this for ... slices. 2b. Do this for closure structs. 2c. Do this for runtime.concatstring, which is the implementation of large string additions. Change representation of OADDSTR to an explicit list in typecheck to avoid reconstructing list in both walk and order. 3. Let orderexpr allocate the temporary variable copies used for range loops, so that they can be killed when the loop is over. Similarly, let it allocate the temporary holding the map iterator. CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. This CL reduces the number to 121. Still more to do, but another good checkpoint. Update #7345 LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83090046
2014-04-01 18:02:54 -06:00
}
print26((*int)(nil), (*int)(nil), (*int)(nil)) // ERROR "live at call to print26: autotmp_[0-9]+$"
print26((*int)(nil), (*int)(nil), (*int)(nil)) // ERROR "live at call to print26: autotmp_[0-9]+$"
printnl()
cmd/gc: shorten more temporary lifetimes 1. In functions with heap-allocated result variables or with defer statements, the return sequence requires more than just a single RET instruction. There is an optimization that arranges for all returns to jump to a single copy of the return epilogue in this case. Unfortunately, that optimization is fundamentally incompatible with PC-based liveness information: it takes PCs at many different points in the function and makes them all land at one PC, making the combined liveness information at that target PC a mess. Disable this optimization, so that each return site gets its own copy of the 'call deferreturn' and the copying of result variables back from the heap. This removes quite a few spurious 'ambiguously live' variables. 2. Let orderexpr allocate temporaries that are passed by address to a function call and then die on return, so that we can arrange an appropriate VARKILL. 2a. Do this for ... slices. 2b. Do this for closure structs. 2c. Do this for runtime.concatstring, which is the implementation of large string additions. Change representation of OADDSTR to an explicit list in typecheck to avoid reconstructing list in both walk and order. 3. Let orderexpr allocate the temporary variable copies used for range loops, so that they can be killed when the loop is over. Similarly, let it allocate the temporary holding the map iterator. CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. This CL reduces the number to 121. Still more to do, but another good checkpoint. Update #7345 LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83090046
2014-04-01 18:02:54 -06:00
}
//go:noescape
func print26(...interface{})
// non-escaping closures passed to function call should die on return
func f27(b bool) {
x := 0
if b {
call27(func() { x++ }) // ERROR "live at call to call27: autotmp_[0-9]+$"
cmd/gc: shorten more temporary lifetimes 1. In functions with heap-allocated result variables or with defer statements, the return sequence requires more than just a single RET instruction. There is an optimization that arranges for all returns to jump to a single copy of the return epilogue in this case. Unfortunately, that optimization is fundamentally incompatible with PC-based liveness information: it takes PCs at many different points in the function and makes them all land at one PC, making the combined liveness information at that target PC a mess. Disable this optimization, so that each return site gets its own copy of the 'call deferreturn' and the copying of result variables back from the heap. This removes quite a few spurious 'ambiguously live' variables. 2. Let orderexpr allocate temporaries that are passed by address to a function call and then die on return, so that we can arrange an appropriate VARKILL. 2a. Do this for ... slices. 2b. Do this for closure structs. 2c. Do this for runtime.concatstring, which is the implementation of large string additions. Change representation of OADDSTR to an explicit list in typecheck to avoid reconstructing list in both walk and order. 3. Let orderexpr allocate the temporary variable copies used for range loops, so that they can be killed when the loop is over. Similarly, let it allocate the temporary holding the map iterator. CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. This CL reduces the number to 121. Still more to do, but another good checkpoint. Update #7345 LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83090046
2014-04-01 18:02:54 -06:00
}
call27(func() { x++ }) // ERROR "live at call to call27: autotmp_[0-9]+$"
call27(func() { x++ }) // ERROR "live at call to call27: autotmp_[0-9]+$"
printnl()
cmd/gc, runtime: make GODEBUG=gcdead=1 mode work with liveness Trying to make GODEBUG=gcdead=1 work with liveness and in particular ambiguously live variables. 1. In the liveness computation, mark all ambiguously live variables as live for the entire function, except the entry. They are zeroed directly after entry, and we need them not to be poisoned thereafter. 2. In the liveness computation, compute liveness (and deadness) for all parameters, not just pointer-containing parameters. Otherwise gcdead poisons untracked scalar parameters and results. 3. Fix liveness debugging print for -live=2 to use correct bitmaps. (Was not updated for compaction during compaction CL.) 4. Correct varkill during map literal initialization. Was killing the map itself instead of the inserted value temp. 5. Disable aggressive varkill cleanup for call arguments if the call appears in a defer or go statement. 6. In the garbage collector, avoid bug scanning empty strings. An empty string is two zeros. The multiword code only looked at the first zero and then interpreted the next two bits in the bitmap as an ordinary word bitmap. For a string the bits are 11 00, so if a live string was zero length with a 0 base pointer, the poisoning code treated the length as an ordinary word with code 00, meaning it needed poisoning, turning the string into a poison-length string with base pointer 0. By the same logic I believe that a live nil slice (bits 11 01 00) will have its cap poisoned. Always scan full multiword struct. 7. In the runtime, treat both poison words (PoisonGC and PoisonStack) as invalid pointers that warrant crashes. Manual testing as follows: - Create a script called gcdead on your PATH containing: #!/bin/bash GODEBUG=gcdead=1 GOGC=10 GOTRACEBACK=2 exec "$@" - Now you can build a test and then run 'gcdead ./foo.test'. - More importantly, you can run 'go test -short -exec gcdead std' to run all the tests. Fixes #7676. While here, enable the precise scanning of slices, since that was disabled due to bugs like these. That now works, both with and without gcdead. Fixes #7549. LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83410044
2014-04-03 18:33:25 -06:00
}
// but defer does escape to later execution in the function
func f27defer(b bool) {
x := 0
if b {
defer call27(func() { x++ }) // ERROR "live at call to deferproc: autotmp_[0-9]+$" "live at call to deferreturn: autotmp_[0-9]+$"
cmd/gc, runtime: make GODEBUG=gcdead=1 mode work with liveness Trying to make GODEBUG=gcdead=1 work with liveness and in particular ambiguously live variables. 1. In the liveness computation, mark all ambiguously live variables as live for the entire function, except the entry. They are zeroed directly after entry, and we need them not to be poisoned thereafter. 2. In the liveness computation, compute liveness (and deadness) for all parameters, not just pointer-containing parameters. Otherwise gcdead poisons untracked scalar parameters and results. 3. Fix liveness debugging print for -live=2 to use correct bitmaps. (Was not updated for compaction during compaction CL.) 4. Correct varkill during map literal initialization. Was killing the map itself instead of the inserted value temp. 5. Disable aggressive varkill cleanup for call arguments if the call appears in a defer or go statement. 6. In the garbage collector, avoid bug scanning empty strings. An empty string is two zeros. The multiword code only looked at the first zero and then interpreted the next two bits in the bitmap as an ordinary word bitmap. For a string the bits are 11 00, so if a live string was zero length with a 0 base pointer, the poisoning code treated the length as an ordinary word with code 00, meaning it needed poisoning, turning the string into a poison-length string with base pointer 0. By the same logic I believe that a live nil slice (bits 11 01 00) will have its cap poisoned. Always scan full multiword struct. 7. In the runtime, treat both poison words (PoisonGC and PoisonStack) as invalid pointers that warrant crashes. Manual testing as follows: - Create a script called gcdead on your PATH containing: #!/bin/bash GODEBUG=gcdead=1 GOGC=10 GOTRACEBACK=2 exec "$@" - Now you can build a test and then run 'gcdead ./foo.test'. - More importantly, you can run 'go test -short -exec gcdead std' to run all the tests. Fixes #7676. While here, enable the precise scanning of slices, since that was disabled due to bugs like these. That now works, both with and without gcdead. Fixes #7549. LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83410044
2014-04-03 18:33:25 -06:00
}
defer call27(func() { x++ }) // ERROR "f27defer: autotmp_[0-9]+ \(type struct { F uintptr; x \*int }\) is ambiguously live$" "live at call to deferproc: autotmp_[0-9]+ autotmp_[0-9]+$" "live at call to deferreturn: autotmp_[0-9]+ autotmp_[0-9]+$"
printnl() // ERROR "live at call to printnl: autotmp_[0-9]+ autotmp_[0-9]+$"
cmd/gc, runtime: make GODEBUG=gcdead=1 mode work with liveness Trying to make GODEBUG=gcdead=1 work with liveness and in particular ambiguously live variables. 1. In the liveness computation, mark all ambiguously live variables as live for the entire function, except the entry. They are zeroed directly after entry, and we need them not to be poisoned thereafter. 2. In the liveness computation, compute liveness (and deadness) for all parameters, not just pointer-containing parameters. Otherwise gcdead poisons untracked scalar parameters and results. 3. Fix liveness debugging print for -live=2 to use correct bitmaps. (Was not updated for compaction during compaction CL.) 4. Correct varkill during map literal initialization. Was killing the map itself instead of the inserted value temp. 5. Disable aggressive varkill cleanup for call arguments if the call appears in a defer or go statement. 6. In the garbage collector, avoid bug scanning empty strings. An empty string is two zeros. The multiword code only looked at the first zero and then interpreted the next two bits in the bitmap as an ordinary word bitmap. For a string the bits are 11 00, so if a live string was zero length with a 0 base pointer, the poisoning code treated the length as an ordinary word with code 00, meaning it needed poisoning, turning the string into a poison-length string with base pointer 0. By the same logic I believe that a live nil slice (bits 11 01 00) will have its cap poisoned. Always scan full multiword struct. 7. In the runtime, treat both poison words (PoisonGC and PoisonStack) as invalid pointers that warrant crashes. Manual testing as follows: - Create a script called gcdead on your PATH containing: #!/bin/bash GODEBUG=gcdead=1 GOGC=10 GOTRACEBACK=2 exec "$@" - Now you can build a test and then run 'gcdead ./foo.test'. - More importantly, you can run 'go test -short -exec gcdead std' to run all the tests. Fixes #7676. While here, enable the precise scanning of slices, since that was disabled due to bugs like these. That now works, both with and without gcdead. Fixes #7549. LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83410044
2014-04-03 18:33:25 -06:00
} // ERROR "live at call to deferreturn: autotmp_[0-9]+ autotmp_[0-9]+$"
// and newproc (go) escapes to the heap
func f27go(b bool) {
x := 0
if b {
go call27(func() { x++ }) // ERROR "live at call to newobject: &x$" "live at call to newproc: &x$"
cmd/gc, runtime: make GODEBUG=gcdead=1 mode work with liveness Trying to make GODEBUG=gcdead=1 work with liveness and in particular ambiguously live variables. 1. In the liveness computation, mark all ambiguously live variables as live for the entire function, except the entry. They are zeroed directly after entry, and we need them not to be poisoned thereafter. 2. In the liveness computation, compute liveness (and deadness) for all parameters, not just pointer-containing parameters. Otherwise gcdead poisons untracked scalar parameters and results. 3. Fix liveness debugging print for -live=2 to use correct bitmaps. (Was not updated for compaction during compaction CL.) 4. Correct varkill during map literal initialization. Was killing the map itself instead of the inserted value temp. 5. Disable aggressive varkill cleanup for call arguments if the call appears in a defer or go statement. 6. In the garbage collector, avoid bug scanning empty strings. An empty string is two zeros. The multiword code only looked at the first zero and then interpreted the next two bits in the bitmap as an ordinary word bitmap. For a string the bits are 11 00, so if a live string was zero length with a 0 base pointer, the poisoning code treated the length as an ordinary word with code 00, meaning it needed poisoning, turning the string into a poison-length string with base pointer 0. By the same logic I believe that a live nil slice (bits 11 01 00) will have its cap poisoned. Always scan full multiword struct. 7. In the runtime, treat both poison words (PoisonGC and PoisonStack) as invalid pointers that warrant crashes. Manual testing as follows: - Create a script called gcdead on your PATH containing: #!/bin/bash GODEBUG=gcdead=1 GOGC=10 GOTRACEBACK=2 exec "$@" - Now you can build a test and then run 'gcdead ./foo.test'. - More importantly, you can run 'go test -short -exec gcdead std' to run all the tests. Fixes #7676. While here, enable the precise scanning of slices, since that was disabled due to bugs like these. That now works, both with and without gcdead. Fixes #7549. LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83410044
2014-04-03 18:33:25 -06:00
}
go call27(func() { x++ }) // ERROR "live at call to newobject: &x$"
printnl()
cmd/gc: shorten more temporary lifetimes 1. In functions with heap-allocated result variables or with defer statements, the return sequence requires more than just a single RET instruction. There is an optimization that arranges for all returns to jump to a single copy of the return epilogue in this case. Unfortunately, that optimization is fundamentally incompatible with PC-based liveness information: it takes PCs at many different points in the function and makes them all land at one PC, making the combined liveness information at that target PC a mess. Disable this optimization, so that each return site gets its own copy of the 'call deferreturn' and the copying of result variables back from the heap. This removes quite a few spurious 'ambiguously live' variables. 2. Let orderexpr allocate temporaries that are passed by address to a function call and then die on return, so that we can arrange an appropriate VARKILL. 2a. Do this for ... slices. 2b. Do this for closure structs. 2c. Do this for runtime.concatstring, which is the implementation of large string additions. Change representation of OADDSTR to an explicit list in typecheck to avoid reconstructing list in both walk and order. 3. Let orderexpr allocate the temporary variable copies used for range loops, so that they can be killed when the loop is over. Similarly, let it allocate the temporary holding the map iterator. CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. This CL reduces the number to 121. Still more to do, but another good checkpoint. Update #7345 LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83090046
2014-04-01 18:02:54 -06:00
}
//go:noescape
func call27(func())
// concatstring slice should die on return
var s1, s2, s3, s4, s5, s6, s7, s8, s9, s10 string
func f28(b bool) {
if b {
printstring(s1 + s2 + s3 + s4 + s5 + s6 + s7 + s8 + s9 + s10) // ERROR "live at call to concatstrings: autotmp_[0-9]+$" "live at call to printstring: autotmp_[0-9]+$"
cmd/gc: shorten more temporary lifetimes 1. In functions with heap-allocated result variables or with defer statements, the return sequence requires more than just a single RET instruction. There is an optimization that arranges for all returns to jump to a single copy of the return epilogue in this case. Unfortunately, that optimization is fundamentally incompatible with PC-based liveness information: it takes PCs at many different points in the function and makes them all land at one PC, making the combined liveness information at that target PC a mess. Disable this optimization, so that each return site gets its own copy of the 'call deferreturn' and the copying of result variables back from the heap. This removes quite a few spurious 'ambiguously live' variables. 2. Let orderexpr allocate temporaries that are passed by address to a function call and then die on return, so that we can arrange an appropriate VARKILL. 2a. Do this for ... slices. 2b. Do this for closure structs. 2c. Do this for runtime.concatstring, which is the implementation of large string additions. Change representation of OADDSTR to an explicit list in typecheck to avoid reconstructing list in both walk and order. 3. Let orderexpr allocate the temporary variable copies used for range loops, so that they can be killed when the loop is over. Similarly, let it allocate the temporary holding the map iterator. CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. This CL reduces the number to 121. Still more to do, but another good checkpoint. Update #7345 LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83090046
2014-04-01 18:02:54 -06:00
}
printstring(s1 + s2 + s3 + s4 + s5 + s6 + s7 + s8 + s9 + s10) // ERROR "live at call to concatstrings: autotmp_[0-9]+$" "live at call to printstring: autotmp_[0-9]+$"
printstring(s1 + s2 + s3 + s4 + s5 + s6 + s7 + s8 + s9 + s10) // ERROR "live at call to concatstrings: autotmp_[0-9]+$" "live at call to printstring: autotmp_[0-9]+$"
}
cmd/gc: shorten more temporary lifetimes 1. In functions with heap-allocated result variables or with defer statements, the return sequence requires more than just a single RET instruction. There is an optimization that arranges for all returns to jump to a single copy of the return epilogue in this case. Unfortunately, that optimization is fundamentally incompatible with PC-based liveness information: it takes PCs at many different points in the function and makes them all land at one PC, making the combined liveness information at that target PC a mess. Disable this optimization, so that each return site gets its own copy of the 'call deferreturn' and the copying of result variables back from the heap. This removes quite a few spurious 'ambiguously live' variables. 2. Let orderexpr allocate temporaries that are passed by address to a function call and then die on return, so that we can arrange an appropriate VARKILL. 2a. Do this for ... slices. 2b. Do this for closure structs. 2c. Do this for runtime.concatstring, which is the implementation of large string additions. Change representation of OADDSTR to an explicit list in typecheck to avoid reconstructing list in both walk and order. 3. Let orderexpr allocate the temporary variable copies used for range loops, so that they can be killed when the loop is over. Similarly, let it allocate the temporary holding the map iterator. CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. This CL reduces the number to 121. Still more to do, but another good checkpoint. Update #7345 LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83090046
2014-04-01 18:02:54 -06:00
// map iterator should die on end of range loop
func f29(b bool) {
if b {
for k := range m { // ERROR "live at call to mapiterinit: autotmp_[0-9]+$" "live at call to mapiternext: autotmp_[0-9]+$"
printstring(k) // ERROR "live at call to printstring: autotmp_[0-9]+$"
cmd/gc: shorten more temporary lifetimes 1. In functions with heap-allocated result variables or with defer statements, the return sequence requires more than just a single RET instruction. There is an optimization that arranges for all returns to jump to a single copy of the return epilogue in this case. Unfortunately, that optimization is fundamentally incompatible with PC-based liveness information: it takes PCs at many different points in the function and makes them all land at one PC, making the combined liveness information at that target PC a mess. Disable this optimization, so that each return site gets its own copy of the 'call deferreturn' and the copying of result variables back from the heap. This removes quite a few spurious 'ambiguously live' variables. 2. Let orderexpr allocate temporaries that are passed by address to a function call and then die on return, so that we can arrange an appropriate VARKILL. 2a. Do this for ... slices. 2b. Do this for closure structs. 2c. Do this for runtime.concatstring, which is the implementation of large string additions. Change representation of OADDSTR to an explicit list in typecheck to avoid reconstructing list in both walk and order. 3. Let orderexpr allocate the temporary variable copies used for range loops, so that they can be killed when the loop is over. Similarly, let it allocate the temporary holding the map iterator. CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. This CL reduces the number to 121. Still more to do, but another good checkpoint. Update #7345 LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83090046
2014-04-01 18:02:54 -06:00
}
}
for k := range m { // ERROR "live at call to mapiterinit: autotmp_[0-9]+$" "live at call to mapiternext: autotmp_[0-9]+$"
printstring(k) // ERROR "live at call to printstring: autotmp_[0-9]+$"
cmd/gc: shorten more temporary lifetimes 1. In functions with heap-allocated result variables or with defer statements, the return sequence requires more than just a single RET instruction. There is an optimization that arranges for all returns to jump to a single copy of the return epilogue in this case. Unfortunately, that optimization is fundamentally incompatible with PC-based liveness information: it takes PCs at many different points in the function and makes them all land at one PC, making the combined liveness information at that target PC a mess. Disable this optimization, so that each return site gets its own copy of the 'call deferreturn' and the copying of result variables back from the heap. This removes quite a few spurious 'ambiguously live' variables. 2. Let orderexpr allocate temporaries that are passed by address to a function call and then die on return, so that we can arrange an appropriate VARKILL. 2a. Do this for ... slices. 2b. Do this for closure structs. 2c. Do this for runtime.concatstring, which is the implementation of large string additions. Change representation of OADDSTR to an explicit list in typecheck to avoid reconstructing list in both walk and order. 3. Let orderexpr allocate the temporary variable copies used for range loops, so that they can be killed when the loop is over. Similarly, let it allocate the temporary holding the map iterator. CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. This CL reduces the number to 121. Still more to do, but another good checkpoint. Update #7345 LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83090046
2014-04-01 18:02:54 -06:00
}
for k := range m { // ERROR "live at call to mapiterinit: autotmp_[0-9]+$" "live at call to mapiternext: autotmp_[0-9]+$"
printstring(k) // ERROR "live at call to printstring: autotmp_[0-9]+$"
cmd/gc: shorten more temporary lifetimes 1. In functions with heap-allocated result variables or with defer statements, the return sequence requires more than just a single RET instruction. There is an optimization that arranges for all returns to jump to a single copy of the return epilogue in this case. Unfortunately, that optimization is fundamentally incompatible with PC-based liveness information: it takes PCs at many different points in the function and makes them all land at one PC, making the combined liveness information at that target PC a mess. Disable this optimization, so that each return site gets its own copy of the 'call deferreturn' and the copying of result variables back from the heap. This removes quite a few spurious 'ambiguously live' variables. 2. Let orderexpr allocate temporaries that are passed by address to a function call and then die on return, so that we can arrange an appropriate VARKILL. 2a. Do this for ... slices. 2b. Do this for closure structs. 2c. Do this for runtime.concatstring, which is the implementation of large string additions. Change representation of OADDSTR to an explicit list in typecheck to avoid reconstructing list in both walk and order. 3. Let orderexpr allocate the temporary variable copies used for range loops, so that they can be killed when the loop is over. Similarly, let it allocate the temporary holding the map iterator. CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. This CL reduces the number to 121. Still more to do, but another good checkpoint. Update #7345 LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83090046
2014-04-01 18:02:54 -06:00
}
}
// copy of array of pointers should die at end of range loop
var ptrarr [10]*int
func f30(b bool) {
// two live temps during print(p):
// the copy of ptrarr and the internal iterator pointer.
if b {
for _, p := range ptrarr {
printintpointer(p) // ERROR "live at call to printintpointer: autotmp_[0-9]+ autotmp_[0-9]+$"
cmd/gc: shorten more temporary lifetimes 1. In functions with heap-allocated result variables or with defer statements, the return sequence requires more than just a single RET instruction. There is an optimization that arranges for all returns to jump to a single copy of the return epilogue in this case. Unfortunately, that optimization is fundamentally incompatible with PC-based liveness information: it takes PCs at many different points in the function and makes them all land at one PC, making the combined liveness information at that target PC a mess. Disable this optimization, so that each return site gets its own copy of the 'call deferreturn' and the copying of result variables back from the heap. This removes quite a few spurious 'ambiguously live' variables. 2. Let orderexpr allocate temporaries that are passed by address to a function call and then die on return, so that we can arrange an appropriate VARKILL. 2a. Do this for ... slices. 2b. Do this for closure structs. 2c. Do this for runtime.concatstring, which is the implementation of large string additions. Change representation of OADDSTR to an explicit list in typecheck to avoid reconstructing list in both walk and order. 3. Let orderexpr allocate the temporary variable copies used for range loops, so that they can be killed when the loop is over. Similarly, let it allocate the temporary holding the map iterator. CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. This CL reduces the number to 121. Still more to do, but another good checkpoint. Update #7345 LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83090046
2014-04-01 18:02:54 -06:00
}
}
for _, p := range ptrarr {
printintpointer(p) // ERROR "live at call to printintpointer: autotmp_[0-9]+ autotmp_[0-9]+$"
cmd/gc: shorten more temporary lifetimes 1. In functions with heap-allocated result variables or with defer statements, the return sequence requires more than just a single RET instruction. There is an optimization that arranges for all returns to jump to a single copy of the return epilogue in this case. Unfortunately, that optimization is fundamentally incompatible with PC-based liveness information: it takes PCs at many different points in the function and makes them all land at one PC, making the combined liveness information at that target PC a mess. Disable this optimization, so that each return site gets its own copy of the 'call deferreturn' and the copying of result variables back from the heap. This removes quite a few spurious 'ambiguously live' variables. 2. Let orderexpr allocate temporaries that are passed by address to a function call and then die on return, so that we can arrange an appropriate VARKILL. 2a. Do this for ... slices. 2b. Do this for closure structs. 2c. Do this for runtime.concatstring, which is the implementation of large string additions. Change representation of OADDSTR to an explicit list in typecheck to avoid reconstructing list in both walk and order. 3. Let orderexpr allocate the temporary variable copies used for range loops, so that they can be killed when the loop is over. Similarly, let it allocate the temporary holding the map iterator. CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. This CL reduces the number to 121. Still more to do, but another good checkpoint. Update #7345 LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83090046
2014-04-01 18:02:54 -06:00
}
for _, p := range ptrarr {
printintpointer(p) // ERROR "live at call to printintpointer: autotmp_[0-9]+ autotmp_[0-9]+$"
cmd/gc: shorten more temporary lifetimes 1. In functions with heap-allocated result variables or with defer statements, the return sequence requires more than just a single RET instruction. There is an optimization that arranges for all returns to jump to a single copy of the return epilogue in this case. Unfortunately, that optimization is fundamentally incompatible with PC-based liveness information: it takes PCs at many different points in the function and makes them all land at one PC, making the combined liveness information at that target PC a mess. Disable this optimization, so that each return site gets its own copy of the 'call deferreturn' and the copying of result variables back from the heap. This removes quite a few spurious 'ambiguously live' variables. 2. Let orderexpr allocate temporaries that are passed by address to a function call and then die on return, so that we can arrange an appropriate VARKILL. 2a. Do this for ... slices. 2b. Do this for closure structs. 2c. Do this for runtime.concatstring, which is the implementation of large string additions. Change representation of OADDSTR to an explicit list in typecheck to avoid reconstructing list in both walk and order. 3. Let orderexpr allocate the temporary variable copies used for range loops, so that they can be killed when the loop is over. Similarly, let it allocate the temporary holding the map iterator. CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. This CL reduces the number to 121. Still more to do, but another good checkpoint. Update #7345 LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83090046
2014-04-01 18:02:54 -06:00
}
}
cmd/gc: shorten even more temporary lifetimes 1. Use n->alloc, not n->left, to hold the allocated temp being passed from orderstmt/orderexpr to walk. 2. Treat method values the same as closures. 3. Use killed temporary for composite literal passed to non-escaping function argument. 4. Clean temporaries promptly in if and for statements. 5. Clean temporaries promptly in select statements. As part of this, move all the temporary-generating logic out of select.c into order.c, so that the temporaries can be reclaimed. With the new temporaries, can re-enable the 1-entry select optimization. Fixes issue 7672. While we're here, fix a 1-line bug in select processing turned up by the new liveness test (but unrelated; select.c:72). Fixes #7686. 6. Clean temporaries (but not particularly promptly) in switch and range statements. 7. Clean temporary used during convT2E/convT2I. 8. Clean temporaries promptly during && and || expressions. --- CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. CL 83090046 reduced the number from 711 to 121. This CL reduces the number from 121 to 23. 15 the 23 that remain are in fact ambiguously live. The final 8 could be fixed but are not trivial and not common enough to warrant work at this point in the release cycle. These numbers only count ambiguously live temps, not ambiguously live user-declared variables. There are 18 such variables in the godoc binary after this CL, so a total of 41 ambiguously live temps or user-declared variables. The net effect is that zeroing anything on entry to a function should now be a rare event, whereas earlier it was the common case. This is good enough for Go 1.3, and probably good enough for future releases too. Fixes #7345. LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83000048
2014-04-02 12:09:42 -06:00
// conversion to interface should not leave temporary behind
func f31(b1, b2, b3 bool) {
if b1 {
g31("a") // ERROR "live at call to convT2E: autotmp_[0-9]+$" "live at call to g31: autotmp_[0-9]+$"
}
if b2 {
h31("b") // ERROR "live at call to convT2E: autotmp_[0-9]+ autotmp_[0-9]+$" "live at call to h31: autotmp_[0-9]+$" "live at call to newobject: autotmp_[0-9]+$"
cmd/gc: shorten even more temporary lifetimes 1. Use n->alloc, not n->left, to hold the allocated temp being passed from orderstmt/orderexpr to walk. 2. Treat method values the same as closures. 3. Use killed temporary for composite literal passed to non-escaping function argument. 4. Clean temporaries promptly in if and for statements. 5. Clean temporaries promptly in select statements. As part of this, move all the temporary-generating logic out of select.c into order.c, so that the temporaries can be reclaimed. With the new temporaries, can re-enable the 1-entry select optimization. Fixes issue 7672. While we're here, fix a 1-line bug in select processing turned up by the new liveness test (but unrelated; select.c:72). Fixes #7686. 6. Clean temporaries (but not particularly promptly) in switch and range statements. 7. Clean temporary used during convT2E/convT2I. 8. Clean temporaries promptly during && and || expressions. --- CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. CL 83090046 reduced the number from 711 to 121. This CL reduces the number from 121 to 23. 15 the 23 that remain are in fact ambiguously live. The final 8 could be fixed but are not trivial and not common enough to warrant work at this point in the release cycle. These numbers only count ambiguously live temps, not ambiguously live user-declared variables. There are 18 such variables in the godoc binary after this CL, so a total of 41 ambiguously live temps or user-declared variables. The net effect is that zeroing anything on entry to a function should now be a rare event, whereas earlier it was the common case. This is good enough for Go 1.3, and probably good enough for future releases too. Fixes #7345. LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83000048
2014-04-02 12:09:42 -06:00
}
if b3 {
panic("asdf") // ERROR "live at call to convT2E: autotmp_[0-9]+$" "live at call to gopanic: autotmp_[0-9]+$"
cmd/gc: shorten even more temporary lifetimes 1. Use n->alloc, not n->left, to hold the allocated temp being passed from orderstmt/orderexpr to walk. 2. Treat method values the same as closures. 3. Use killed temporary for composite literal passed to non-escaping function argument. 4. Clean temporaries promptly in if and for statements. 5. Clean temporaries promptly in select statements. As part of this, move all the temporary-generating logic out of select.c into order.c, so that the temporaries can be reclaimed. With the new temporaries, can re-enable the 1-entry select optimization. Fixes issue 7672. While we're here, fix a 1-line bug in select processing turned up by the new liveness test (but unrelated; select.c:72). Fixes #7686. 6. Clean temporaries (but not particularly promptly) in switch and range statements. 7. Clean temporary used during convT2E/convT2I. 8. Clean temporaries promptly during && and || expressions. --- CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. CL 83090046 reduced the number from 711 to 121. This CL reduces the number from 121 to 23. 15 the 23 that remain are in fact ambiguously live. The final 8 could be fixed but are not trivial and not common enough to warrant work at this point in the release cycle. These numbers only count ambiguously live temps, not ambiguously live user-declared variables. There are 18 such variables in the godoc binary after this CL, so a total of 41 ambiguously live temps or user-declared variables. The net effect is that zeroing anything on entry to a function should now be a rare event, whereas earlier it was the common case. This is good enough for Go 1.3, and probably good enough for future releases too. Fixes #7345. LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83000048
2014-04-02 12:09:42 -06:00
}
print(b3)
}
func g31(interface{})
func h31(...interface{})
// non-escaping partial functions passed to function call should die on return
type T32 int
func (t *T32) Inc() { // ERROR "live at entry to \(\*T32\).Inc: t$"
cmd/gc: shorten even more temporary lifetimes 1. Use n->alloc, not n->left, to hold the allocated temp being passed from orderstmt/orderexpr to walk. 2. Treat method values the same as closures. 3. Use killed temporary for composite literal passed to non-escaping function argument. 4. Clean temporaries promptly in if and for statements. 5. Clean temporaries promptly in select statements. As part of this, move all the temporary-generating logic out of select.c into order.c, so that the temporaries can be reclaimed. With the new temporaries, can re-enable the 1-entry select optimization. Fixes issue 7672. While we're here, fix a 1-line bug in select processing turned up by the new liveness test (but unrelated; select.c:72). Fixes #7686. 6. Clean temporaries (but not particularly promptly) in switch and range statements. 7. Clean temporary used during convT2E/convT2I. 8. Clean temporaries promptly during && and || expressions. --- CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. CL 83090046 reduced the number from 711 to 121. This CL reduces the number from 121 to 23. 15 the 23 that remain are in fact ambiguously live. The final 8 could be fixed but are not trivial and not common enough to warrant work at this point in the release cycle. These numbers only count ambiguously live temps, not ambiguously live user-declared variables. There are 18 such variables in the godoc binary after this CL, so a total of 41 ambiguously live temps or user-declared variables. The net effect is that zeroing anything on entry to a function should now be a rare event, whereas earlier it was the common case. This is good enough for Go 1.3, and probably good enough for future releases too. Fixes #7345. LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83000048
2014-04-02 12:09:42 -06:00
*t++
}
var t32 T32
func f32(b bool) {
if b {
call32(t32.Inc) // ERROR "live at call to call32: autotmp_[0-9]+$"
}
call32(t32.Inc) // ERROR "live at call to call32: autotmp_[0-9]+$"
call32(t32.Inc) // ERROR "live at call to call32: autotmp_[0-9]+$"
}
//go:noescape
func call32(func())
// temporaries introduced during if conditions and && || expressions
// should die once the condition has been acted upon.
var m33 map[interface{}]int
func f33() {
if m33[nil] == 0 { // ERROR "live at call to mapaccess1: autotmp_[0-9]+$"
printnl()
cmd/gc: shorten even more temporary lifetimes 1. Use n->alloc, not n->left, to hold the allocated temp being passed from orderstmt/orderexpr to walk. 2. Treat method values the same as closures. 3. Use killed temporary for composite literal passed to non-escaping function argument. 4. Clean temporaries promptly in if and for statements. 5. Clean temporaries promptly in select statements. As part of this, move all the temporary-generating logic out of select.c into order.c, so that the temporaries can be reclaimed. With the new temporaries, can re-enable the 1-entry select optimization. Fixes issue 7672. While we're here, fix a 1-line bug in select processing turned up by the new liveness test (but unrelated; select.c:72). Fixes #7686. 6. Clean temporaries (but not particularly promptly) in switch and range statements. 7. Clean temporary used during convT2E/convT2I. 8. Clean temporaries promptly during && and || expressions. --- CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. CL 83090046 reduced the number from 711 to 121. This CL reduces the number from 121 to 23. 15 the 23 that remain are in fact ambiguously live. The final 8 could be fixed but are not trivial and not common enough to warrant work at this point in the release cycle. These numbers only count ambiguously live temps, not ambiguously live user-declared variables. There are 18 such variables in the godoc binary after this CL, so a total of 41 ambiguously live temps or user-declared variables. The net effect is that zeroing anything on entry to a function should now be a rare event, whereas earlier it was the common case. This is good enough for Go 1.3, and probably good enough for future releases too. Fixes #7345. LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83000048
2014-04-02 12:09:42 -06:00
return
} else {
printnl()
cmd/gc: shorten even more temporary lifetimes 1. Use n->alloc, not n->left, to hold the allocated temp being passed from orderstmt/orderexpr to walk. 2. Treat method values the same as closures. 3. Use killed temporary for composite literal passed to non-escaping function argument. 4. Clean temporaries promptly in if and for statements. 5. Clean temporaries promptly in select statements. As part of this, move all the temporary-generating logic out of select.c into order.c, so that the temporaries can be reclaimed. With the new temporaries, can re-enable the 1-entry select optimization. Fixes issue 7672. While we're here, fix a 1-line bug in select processing turned up by the new liveness test (but unrelated; select.c:72). Fixes #7686. 6. Clean temporaries (but not particularly promptly) in switch and range statements. 7. Clean temporary used during convT2E/convT2I. 8. Clean temporaries promptly during && and || expressions. --- CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. CL 83090046 reduced the number from 711 to 121. This CL reduces the number from 121 to 23. 15 the 23 that remain are in fact ambiguously live. The final 8 could be fixed but are not trivial and not common enough to warrant work at this point in the release cycle. These numbers only count ambiguously live temps, not ambiguously live user-declared variables. There are 18 such variables in the godoc binary after this CL, so a total of 41 ambiguously live temps or user-declared variables. The net effect is that zeroing anything on entry to a function should now be a rare event, whereas earlier it was the common case. This is good enough for Go 1.3, and probably good enough for future releases too. Fixes #7345. LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83000048
2014-04-02 12:09:42 -06:00
}
printnl()
cmd/gc: shorten even more temporary lifetimes 1. Use n->alloc, not n->left, to hold the allocated temp being passed from orderstmt/orderexpr to walk. 2. Treat method values the same as closures. 3. Use killed temporary for composite literal passed to non-escaping function argument. 4. Clean temporaries promptly in if and for statements. 5. Clean temporaries promptly in select statements. As part of this, move all the temporary-generating logic out of select.c into order.c, so that the temporaries can be reclaimed. With the new temporaries, can re-enable the 1-entry select optimization. Fixes issue 7672. While we're here, fix a 1-line bug in select processing turned up by the new liveness test (but unrelated; select.c:72). Fixes #7686. 6. Clean temporaries (but not particularly promptly) in switch and range statements. 7. Clean temporary used during convT2E/convT2I. 8. Clean temporaries promptly during && and || expressions. --- CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. CL 83090046 reduced the number from 711 to 121. This CL reduces the number from 121 to 23. 15 the 23 that remain are in fact ambiguously live. The final 8 could be fixed but are not trivial and not common enough to warrant work at this point in the release cycle. These numbers only count ambiguously live temps, not ambiguously live user-declared variables. There are 18 such variables in the godoc binary after this CL, so a total of 41 ambiguously live temps or user-declared variables. The net effect is that zeroing anything on entry to a function should now be a rare event, whereas earlier it was the common case. This is good enough for Go 1.3, and probably good enough for future releases too. Fixes #7345. LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83000048
2014-04-02 12:09:42 -06:00
}
func f34() {
if m33[nil] == 0 { // ERROR "live at call to mapaccess1: autotmp_[0-9]+$"
printnl()
cmd/gc: shorten even more temporary lifetimes 1. Use n->alloc, not n->left, to hold the allocated temp being passed from orderstmt/orderexpr to walk. 2. Treat method values the same as closures. 3. Use killed temporary for composite literal passed to non-escaping function argument. 4. Clean temporaries promptly in if and for statements. 5. Clean temporaries promptly in select statements. As part of this, move all the temporary-generating logic out of select.c into order.c, so that the temporaries can be reclaimed. With the new temporaries, can re-enable the 1-entry select optimization. Fixes issue 7672. While we're here, fix a 1-line bug in select processing turned up by the new liveness test (but unrelated; select.c:72). Fixes #7686. 6. Clean temporaries (but not particularly promptly) in switch and range statements. 7. Clean temporary used during convT2E/convT2I. 8. Clean temporaries promptly during && and || expressions. --- CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. CL 83090046 reduced the number from 711 to 121. This CL reduces the number from 121 to 23. 15 the 23 that remain are in fact ambiguously live. The final 8 could be fixed but are not trivial and not common enough to warrant work at this point in the release cycle. These numbers only count ambiguously live temps, not ambiguously live user-declared variables. There are 18 such variables in the godoc binary after this CL, so a total of 41 ambiguously live temps or user-declared variables. The net effect is that zeroing anything on entry to a function should now be a rare event, whereas earlier it was the common case. This is good enough for Go 1.3, and probably good enough for future releases too. Fixes #7345. LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83000048
2014-04-02 12:09:42 -06:00
return
}
printnl()
cmd/gc: shorten even more temporary lifetimes 1. Use n->alloc, not n->left, to hold the allocated temp being passed from orderstmt/orderexpr to walk. 2. Treat method values the same as closures. 3. Use killed temporary for composite literal passed to non-escaping function argument. 4. Clean temporaries promptly in if and for statements. 5. Clean temporaries promptly in select statements. As part of this, move all the temporary-generating logic out of select.c into order.c, so that the temporaries can be reclaimed. With the new temporaries, can re-enable the 1-entry select optimization. Fixes issue 7672. While we're here, fix a 1-line bug in select processing turned up by the new liveness test (but unrelated; select.c:72). Fixes #7686. 6. Clean temporaries (but not particularly promptly) in switch and range statements. 7. Clean temporary used during convT2E/convT2I. 8. Clean temporaries promptly during && and || expressions. --- CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. CL 83090046 reduced the number from 711 to 121. This CL reduces the number from 121 to 23. 15 the 23 that remain are in fact ambiguously live. The final 8 could be fixed but are not trivial and not common enough to warrant work at this point in the release cycle. These numbers only count ambiguously live temps, not ambiguously live user-declared variables. There are 18 such variables in the godoc binary after this CL, so a total of 41 ambiguously live temps or user-declared variables. The net effect is that zeroing anything on entry to a function should now be a rare event, whereas earlier it was the common case. This is good enough for Go 1.3, and probably good enough for future releases too. Fixes #7345. LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83000048
2014-04-02 12:09:42 -06:00
}
func f35() {
if m33[nil] == 0 && m33[nil] == 0 { // ERROR "live at call to mapaccess1: autotmp_[0-9]+$"
printnl()
cmd/gc: shorten even more temporary lifetimes 1. Use n->alloc, not n->left, to hold the allocated temp being passed from orderstmt/orderexpr to walk. 2. Treat method values the same as closures. 3. Use killed temporary for composite literal passed to non-escaping function argument. 4. Clean temporaries promptly in if and for statements. 5. Clean temporaries promptly in select statements. As part of this, move all the temporary-generating logic out of select.c into order.c, so that the temporaries can be reclaimed. With the new temporaries, can re-enable the 1-entry select optimization. Fixes issue 7672. While we're here, fix a 1-line bug in select processing turned up by the new liveness test (but unrelated; select.c:72). Fixes #7686. 6. Clean temporaries (but not particularly promptly) in switch and range statements. 7. Clean temporary used during convT2E/convT2I. 8. Clean temporaries promptly during && and || expressions. --- CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. CL 83090046 reduced the number from 711 to 121. This CL reduces the number from 121 to 23. 15 the 23 that remain are in fact ambiguously live. The final 8 could be fixed but are not trivial and not common enough to warrant work at this point in the release cycle. These numbers only count ambiguously live temps, not ambiguously live user-declared variables. There are 18 such variables in the godoc binary after this CL, so a total of 41 ambiguously live temps or user-declared variables. The net effect is that zeroing anything on entry to a function should now be a rare event, whereas earlier it was the common case. This is good enough for Go 1.3, and probably good enough for future releases too. Fixes #7345. LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83000048
2014-04-02 12:09:42 -06:00
return
}
printnl()
cmd/gc: shorten even more temporary lifetimes 1. Use n->alloc, not n->left, to hold the allocated temp being passed from orderstmt/orderexpr to walk. 2. Treat method values the same as closures. 3. Use killed temporary for composite literal passed to non-escaping function argument. 4. Clean temporaries promptly in if and for statements. 5. Clean temporaries promptly in select statements. As part of this, move all the temporary-generating logic out of select.c into order.c, so that the temporaries can be reclaimed. With the new temporaries, can re-enable the 1-entry select optimization. Fixes issue 7672. While we're here, fix a 1-line bug in select processing turned up by the new liveness test (but unrelated; select.c:72). Fixes #7686. 6. Clean temporaries (but not particularly promptly) in switch and range statements. 7. Clean temporary used during convT2E/convT2I. 8. Clean temporaries promptly during && and || expressions. --- CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. CL 83090046 reduced the number from 711 to 121. This CL reduces the number from 121 to 23. 15 the 23 that remain are in fact ambiguously live. The final 8 could be fixed but are not trivial and not common enough to warrant work at this point in the release cycle. These numbers only count ambiguously live temps, not ambiguously live user-declared variables. There are 18 such variables in the godoc binary after this CL, so a total of 41 ambiguously live temps or user-declared variables. The net effect is that zeroing anything on entry to a function should now be a rare event, whereas earlier it was the common case. This is good enough for Go 1.3, and probably good enough for future releases too. Fixes #7345. LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83000048
2014-04-02 12:09:42 -06:00
}
func f36() {
if m33[nil] == 0 || m33[nil] == 0 { // ERROR "live at call to mapaccess1: autotmp_[0-9]+$"
printnl()
cmd/gc: shorten even more temporary lifetimes 1. Use n->alloc, not n->left, to hold the allocated temp being passed from orderstmt/orderexpr to walk. 2. Treat method values the same as closures. 3. Use killed temporary for composite literal passed to non-escaping function argument. 4. Clean temporaries promptly in if and for statements. 5. Clean temporaries promptly in select statements. As part of this, move all the temporary-generating logic out of select.c into order.c, so that the temporaries can be reclaimed. With the new temporaries, can re-enable the 1-entry select optimization. Fixes issue 7672. While we're here, fix a 1-line bug in select processing turned up by the new liveness test (but unrelated; select.c:72). Fixes #7686. 6. Clean temporaries (but not particularly promptly) in switch and range statements. 7. Clean temporary used during convT2E/convT2I. 8. Clean temporaries promptly during && and || expressions. --- CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. CL 83090046 reduced the number from 711 to 121. This CL reduces the number from 121 to 23. 15 the 23 that remain are in fact ambiguously live. The final 8 could be fixed but are not trivial and not common enough to warrant work at this point in the release cycle. These numbers only count ambiguously live temps, not ambiguously live user-declared variables. There are 18 such variables in the godoc binary after this CL, so a total of 41 ambiguously live temps or user-declared variables. The net effect is that zeroing anything on entry to a function should now be a rare event, whereas earlier it was the common case. This is good enough for Go 1.3, and probably good enough for future releases too. Fixes #7345. LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83000048
2014-04-02 12:09:42 -06:00
return
}
printnl()
cmd/gc: shorten even more temporary lifetimes 1. Use n->alloc, not n->left, to hold the allocated temp being passed from orderstmt/orderexpr to walk. 2. Treat method values the same as closures. 3. Use killed temporary for composite literal passed to non-escaping function argument. 4. Clean temporaries promptly in if and for statements. 5. Clean temporaries promptly in select statements. As part of this, move all the temporary-generating logic out of select.c into order.c, so that the temporaries can be reclaimed. With the new temporaries, can re-enable the 1-entry select optimization. Fixes issue 7672. While we're here, fix a 1-line bug in select processing turned up by the new liveness test (but unrelated; select.c:72). Fixes #7686. 6. Clean temporaries (but not particularly promptly) in switch and range statements. 7. Clean temporary used during convT2E/convT2I. 8. Clean temporaries promptly during && and || expressions. --- CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. CL 83090046 reduced the number from 711 to 121. This CL reduces the number from 121 to 23. 15 the 23 that remain are in fact ambiguously live. The final 8 could be fixed but are not trivial and not common enough to warrant work at this point in the release cycle. These numbers only count ambiguously live temps, not ambiguously live user-declared variables. There are 18 such variables in the godoc binary after this CL, so a total of 41 ambiguously live temps or user-declared variables. The net effect is that zeroing anything on entry to a function should now be a rare event, whereas earlier it was the common case. This is good enough for Go 1.3, and probably good enough for future releases too. Fixes #7345. LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83000048
2014-04-02 12:09:42 -06:00
}
func f37() {
if (m33[nil] == 0 || m33[nil] == 0) && m33[nil] == 0 { // ERROR "live at call to mapaccess1: autotmp_[0-9]+$"
printnl()
cmd/gc: shorten even more temporary lifetimes 1. Use n->alloc, not n->left, to hold the allocated temp being passed from orderstmt/orderexpr to walk. 2. Treat method values the same as closures. 3. Use killed temporary for composite literal passed to non-escaping function argument. 4. Clean temporaries promptly in if and for statements. 5. Clean temporaries promptly in select statements. As part of this, move all the temporary-generating logic out of select.c into order.c, so that the temporaries can be reclaimed. With the new temporaries, can re-enable the 1-entry select optimization. Fixes issue 7672. While we're here, fix a 1-line bug in select processing turned up by the new liveness test (but unrelated; select.c:72). Fixes #7686. 6. Clean temporaries (but not particularly promptly) in switch and range statements. 7. Clean temporary used during convT2E/convT2I. 8. Clean temporaries promptly during && and || expressions. --- CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. CL 83090046 reduced the number from 711 to 121. This CL reduces the number from 121 to 23. 15 the 23 that remain are in fact ambiguously live. The final 8 could be fixed but are not trivial and not common enough to warrant work at this point in the release cycle. These numbers only count ambiguously live temps, not ambiguously live user-declared variables. There are 18 such variables in the godoc binary after this CL, so a total of 41 ambiguously live temps or user-declared variables. The net effect is that zeroing anything on entry to a function should now be a rare event, whereas earlier it was the common case. This is good enough for Go 1.3, and probably good enough for future releases too. Fixes #7345. LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83000048
2014-04-02 12:09:42 -06:00
return
}
printnl()
cmd/gc: shorten even more temporary lifetimes 1. Use n->alloc, not n->left, to hold the allocated temp being passed from orderstmt/orderexpr to walk. 2. Treat method values the same as closures. 3. Use killed temporary for composite literal passed to non-escaping function argument. 4. Clean temporaries promptly in if and for statements. 5. Clean temporaries promptly in select statements. As part of this, move all the temporary-generating logic out of select.c into order.c, so that the temporaries can be reclaimed. With the new temporaries, can re-enable the 1-entry select optimization. Fixes issue 7672. While we're here, fix a 1-line bug in select processing turned up by the new liveness test (but unrelated; select.c:72). Fixes #7686. 6. Clean temporaries (but not particularly promptly) in switch and range statements. 7. Clean temporary used during convT2E/convT2I. 8. Clean temporaries promptly during && and || expressions. --- CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. CL 83090046 reduced the number from 711 to 121. This CL reduces the number from 121 to 23. 15 the 23 that remain are in fact ambiguously live. The final 8 could be fixed but are not trivial and not common enough to warrant work at this point in the release cycle. These numbers only count ambiguously live temps, not ambiguously live user-declared variables. There are 18 such variables in the godoc binary after this CL, so a total of 41 ambiguously live temps or user-declared variables. The net effect is that zeroing anything on entry to a function should now be a rare event, whereas earlier it was the common case. This is good enough for Go 1.3, and probably good enough for future releases too. Fixes #7345. LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83000048
2014-04-02 12:09:42 -06:00
}
// select temps should disappear in the case bodies
var c38 chan string
func fc38() chan string
func fi38(int) *string
func fb38() *bool
func f38(b bool) {
// we don't care what temps are printed on the lines with output.
// we care that the println lines have no live variables
// and therefore no output.
if b {
select { // ERROR "live at call to newselect: autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+$" "live at call to selectgo: autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+$"
case <-fc38(): // ERROR "live at call to selectrecv: autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+$"
printnl()
case fc38() <- *fi38(1): // ERROR "live at call to fc38: autotmp_[0-9]+$" "live at call to fi38: autotmp_[0-9]+ autotmp_[0-9]+$" "live at call to selectsend: autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+$"
printnl()
case *fi38(2) = <-fc38(): // ERROR "live at call to fc38: autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+$" "live at call to fi38: autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+$" "live at call to selectrecv: autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+$"
printnl()
case *fi38(3), *fb38() = <-fc38(): // ERROR "live at call to fb38: autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+$" "live at call to fc38: autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+$" "live at call to fi38: autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+$" "live at call to selectrecv2: autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+ autotmp_[0-9]+$"
printnl()
cmd/gc: shorten even more temporary lifetimes 1. Use n->alloc, not n->left, to hold the allocated temp being passed from orderstmt/orderexpr to walk. 2. Treat method values the same as closures. 3. Use killed temporary for composite literal passed to non-escaping function argument. 4. Clean temporaries promptly in if and for statements. 5. Clean temporaries promptly in select statements. As part of this, move all the temporary-generating logic out of select.c into order.c, so that the temporaries can be reclaimed. With the new temporaries, can re-enable the 1-entry select optimization. Fixes issue 7672. While we're here, fix a 1-line bug in select processing turned up by the new liveness test (but unrelated; select.c:72). Fixes #7686. 6. Clean temporaries (but not particularly promptly) in switch and range statements. 7. Clean temporary used during convT2E/convT2I. 8. Clean temporaries promptly during && and || expressions. --- CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. CL 83090046 reduced the number from 711 to 121. This CL reduces the number from 121 to 23. 15 the 23 that remain are in fact ambiguously live. The final 8 could be fixed but are not trivial and not common enough to warrant work at this point in the release cycle. These numbers only count ambiguously live temps, not ambiguously live user-declared variables. There are 18 such variables in the godoc binary after this CL, so a total of 41 ambiguously live temps or user-declared variables. The net effect is that zeroing anything on entry to a function should now be a rare event, whereas earlier it was the common case. This is good enough for Go 1.3, and probably good enough for future releases too. Fixes #7345. LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83000048
2014-04-02 12:09:42 -06:00
}
printnl()
cmd/gc: shorten even more temporary lifetimes 1. Use n->alloc, not n->left, to hold the allocated temp being passed from orderstmt/orderexpr to walk. 2. Treat method values the same as closures. 3. Use killed temporary for composite literal passed to non-escaping function argument. 4. Clean temporaries promptly in if and for statements. 5. Clean temporaries promptly in select statements. As part of this, move all the temporary-generating logic out of select.c into order.c, so that the temporaries can be reclaimed. With the new temporaries, can re-enable the 1-entry select optimization. Fixes issue 7672. While we're here, fix a 1-line bug in select processing turned up by the new liveness test (but unrelated; select.c:72). Fixes #7686. 6. Clean temporaries (but not particularly promptly) in switch and range statements. 7. Clean temporary used during convT2E/convT2I. 8. Clean temporaries promptly during && and || expressions. --- CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. CL 83090046 reduced the number from 711 to 121. This CL reduces the number from 121 to 23. 15 the 23 that remain are in fact ambiguously live. The final 8 could be fixed but are not trivial and not common enough to warrant work at this point in the release cycle. These numbers only count ambiguously live temps, not ambiguously live user-declared variables. There are 18 such variables in the godoc binary after this CL, so a total of 41 ambiguously live temps or user-declared variables. The net effect is that zeroing anything on entry to a function should now be a rare event, whereas earlier it was the common case. This is good enough for Go 1.3, and probably good enough for future releases too. Fixes #7345. LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83000048
2014-04-02 12:09:42 -06:00
}
printnl()
cmd/gc: shorten even more temporary lifetimes 1. Use n->alloc, not n->left, to hold the allocated temp being passed from orderstmt/orderexpr to walk. 2. Treat method values the same as closures. 3. Use killed temporary for composite literal passed to non-escaping function argument. 4. Clean temporaries promptly in if and for statements. 5. Clean temporaries promptly in select statements. As part of this, move all the temporary-generating logic out of select.c into order.c, so that the temporaries can be reclaimed. With the new temporaries, can re-enable the 1-entry select optimization. Fixes issue 7672. While we're here, fix a 1-line bug in select processing turned up by the new liveness test (but unrelated; select.c:72). Fixes #7686. 6. Clean temporaries (but not particularly promptly) in switch and range statements. 7. Clean temporary used during convT2E/convT2I. 8. Clean temporaries promptly during && and || expressions. --- CL 81940043 reduced the number of ambiguously live temps in the godoc binary from 860 to 711. CL 83090046 reduced the number from 711 to 121. This CL reduces the number from 121 to 23. 15 the 23 that remain are in fact ambiguously live. The final 8 could be fixed but are not trivial and not common enough to warrant work at this point in the release cycle. These numbers only count ambiguously live temps, not ambiguously live user-declared variables. There are 18 such variables in the godoc binary after this CL, so a total of 41 ambiguously live temps or user-declared variables. The net effect is that zeroing anything on entry to a function should now be a rare event, whereas earlier it was the common case. This is good enough for Go 1.3, and probably good enough for future releases too. Fixes #7345. LGTM=khr R=khr CC=golang-codereviews https://golang.org/cl/83000048
2014-04-02 12:09:42 -06:00
}
// issue 8097: mishandling of x = x during return.
func f39() (x []int) {
x = []int{1}
printnl() // ERROR "live at call to printnl: x$"
return x
}
func f39a() (x []int) {
x = []int{1}
printnl() // ERROR "live at call to printnl: x$"
return
}
func f39b() (x [10]*int) {
x = [10]*int{}
x[0] = new(int) // ERROR "live at call to newobject: x$"
printnl() // ERROR "live at call to printnl: x$"
return x
}
func f39c() (x [10]*int) {
x = [10]*int{}
x[0] = new(int) // ERROR "live at call to newobject: x$"
printnl() // ERROR "live at call to printnl: x$"
return
}
// issue 8142: lost 'addrtaken' bit on inlined variables.
// no inlining in this test, so just checking that non-inlined works.
type T40 struct {
m map[int]int
}
func newT40() *T40 {
ret := T40{}
ret.m = make(map[int]int) // ERROR "live at call to makemap: &ret$"
return &ret
}
func bad40() {
t := newT40()
_ = t
printnl()
}
func good40() {
ret := T40{}
ret.m = make(map[int]int) // ERROR "live at call to makemap: autotmp_[0-9]+ ret$"
t := &ret
printnl() // ERROR "live at call to printnl: autotmp_[0-9]+ ret$"
_ = t
}