go/test/fixedbugs/issue7995b.dir/x1.go

package x1

import "fmt"

var P int

//go:noinline
func F(x *int) string {
	P = 50
	*x = 100
	return fmt.Sprintln(P, *x)
}
cmd/gc: correct handling of globals, func args, results Globals, function arguments, and results are special cases in registerization. Globals must be flushed aggressively, because nearly any operation can cause a panic, and the recovery code must see the latest values. Globals also must be loaded aggressively, because nearly any store through a pointer might be updating a global: the compiler cannot see all the "address of" operations on globals, especially exported globals. To accomplish this, mark all globals as having their address taken, which effectively disables registerization. If a function contains a defer statement, the function results must be flushed aggressively, because nearly any operation can cause a panic, and the deferred code may call recover, causing the original function to return the current values of its function results. To accomplish this, mark all function results as having their address taken if the function contains any defer statements. This causes not just aggressive flushing but also aggressive loading. The aggressive loading is overkill but the best we can do in the current code. Function arguments must be considered live at all safe points in a function, because garbage collection always preserves them: they must be up-to-date in order to be preserved correctly. Accomplish this by marking them live at all call sites. An earlier attempt at this marked function arguments as having their address taken, which disabled registerization completely, making programs slower. This CL's solution allows registerization while preserving safety. The benchmark speedup is caused by being able to registerize again (the earlier CL lost the same amount). benchmark old ns/op new ns/op delta BenchmarkEqualPort32 61.4 56.0 -8.79% benchmark old MB/s new MB/s speedup BenchmarkEqualPort32 521.56 570.97 1.09x Fixes #1304. (again) Fixes #7944. (again) Fixes #7984. Fixes #7995. LGTM=khr R=golang-codereviews, khr CC=golang-codereviews, iant, r https://golang.org/cl/97500044 2014-05-15 13:34:53 -06:00			`package x1`

			`import "fmt"`

			`var P int`

test: use go:noinline consistently Replace various implementations of inlining prevention with "go:noinline" Change-Id: Iac90895c3a62d6f4b7a6c72e11e165d15a0abfa4 Reviewed-on: https://go-review.googlesource.com/16510 Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Todd Neal <todd@tneal.org> TryBot-Result: Gobot Gobot <gobot@golang.org> 2015-10-29 20:45:19 -06:00			`//go:noinline`
cmd/gc: correct handling of globals, func args, results Globals, function arguments, and results are special cases in registerization. Globals must be flushed aggressively, because nearly any operation can cause a panic, and the recovery code must see the latest values. Globals also must be loaded aggressively, because nearly any store through a pointer might be updating a global: the compiler cannot see all the "address of" operations on globals, especially exported globals. To accomplish this, mark all globals as having their address taken, which effectively disables registerization. If a function contains a defer statement, the function results must be flushed aggressively, because nearly any operation can cause a panic, and the deferred code may call recover, causing the original function to return the current values of its function results. To accomplish this, mark all function results as having their address taken if the function contains any defer statements. This causes not just aggressive flushing but also aggressive loading. The aggressive loading is overkill but the best we can do in the current code. Function arguments must be considered live at all safe points in a function, because garbage collection always preserves them: they must be up-to-date in order to be preserved correctly. Accomplish this by marking them live at all call sites. An earlier attempt at this marked function arguments as having their address taken, which disabled registerization completely, making programs slower. This CL's solution allows registerization while preserving safety. The benchmark speedup is caused by being able to registerize again (the earlier CL lost the same amount). benchmark old ns/op new ns/op delta BenchmarkEqualPort32 61.4 56.0 -8.79% benchmark old MB/s new MB/s speedup BenchmarkEqualPort32 521.56 570.97 1.09x Fixes #1304. (again) Fixes #7944. (again) Fixes #7984. Fixes #7995. LGTM=khr R=golang-codereviews, khr CC=golang-codereviews, iant, r https://golang.org/cl/97500044 2014-05-15 13:34:53 -06:00			`func F(x *int) string {`
			`P = 50`
			`*x = 100`
			`return fmt.Sprintln(P, *x)`
			`}`