go/test/live.go

124 lines
2.4 KiB
Go
Raw Normal View History

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 15:32:30 +00:00
// errorcheck -0 -l -live
// 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.
package main
func f1() {
var x *int
print(&x) // ERROR "live at call to printpointer: x$"
print(&x) // ERROR "live at call to printpointer: x$"
}
func f2(b bool) {
if b {
print(0) // nothing live here
return
}
var x *int
print(&x) // ERROR "live at call to printpointer: x$"
print(&x) // ERROR "live at call to printpointer: x$"
}
func f3(b bool) {
print(0)
if b == false {
print(0) // nothing live here
return
}
if b {
var x *int
print(&x) // ERROR "live at call to printpointer: x$"
print(&x) // ERROR "live at call to printpointer: x$"
} else {
var y *int
print(&y) // ERROR "live at call to printpointer: y$"
print(&y) // ERROR "live at call to printpointer: y$"
}
print(0) // ERROR "live at call to printint: x y$"
}
// 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 {
print(0) // x not live here
return
}
var z **int
x := new(int)
*x = 42
z = &x
print(**z) // ERROR "live at call to printint: x z$"
if b2 {
print(1) // ERROR "live at call to printint: x$"
return
}
for {
print(**z) // ERROR "live at call to printint: x z$"
}
}
func f5(b1 bool) {
var z **int
if b1 {
x := new(int)
*x = 42
z = &x
} else {
y := new(int)
*y = 54
z = &y
}
print(**z) // ERROR "live at call to printint: x y$"
}
// 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 != 99
}
// liveness formerly confused by UNDEF followed by RET,
// leading to "live at entry to f10: ~r1" (unnamed result).
func f10() string {
panic(1)
}