aboutsummaryrefslogtreecommitdiff
path: root/test/nilptr3.go
diff options
context:
space:
mode:
authorMatthew Dempsky <mdempsky@google.com>2021-01-03 19:49:49 -0800
committerMatthew Dempsky <mdempsky@google.com>2021-01-10 08:01:49 +0000
commit8b2efa990b08e6c32422fbfdab746f4f6948ae42 (patch)
tree975ce31c7d11086e2560d34a9369d92c75b16583 /test/nilptr3.go
parent6ee9b118a2a70371e038fb6bec4fe7989a3a2b2d (diff)
downloadgo-8b2efa990b08e6c32422fbfdab746f4f6948ae42.tar.gz
go-8b2efa990b08e6c32422fbfdab746f4f6948ae42.zip
[dev.regabi] cmd/compile: deref PAUTOHEAPs during SSA construction
Currently, during walk we rewrite PAUTOHEAP uses into derefs of their corresponding Heapaddr, but we can easily do this instead during SSA construction. This does involve updating two test cases: * nilptr3.go This file had a test that we emit a "removed nil check" diagnostic for the implicit dereference from accessing a PAUTOHEAP variable. This CL removes this diagnostic, since it's not really useful to end users: from the user's point of view, there's no pointer anyway, so they needn't care about whether we check for nil or not. That's a purely internal detail. And with the PAUTOHEAP dereference handled during SSA construction, we can more robustly ensure this happens, rather than relying on setting a flag in walk and hoping that SSA sees it. * issue20780.go Previously, when PAUTOHEAPs were dereferenced during walk, it had a consequence that when they're passed as a function call argument, they would first get copied to the stack before being copied to their actual destination. Moving the dereferencing to SSA had a side-effect of eliminating this unnecessary temporary, and copying directly to the destination parameter. The test is updated to instead call "g(h(), h())" where h() returns a large value, as the first result will always need to be spilled somewhere will calling the second function. Maybe eventually we're smart enough to realize it can be spilled to the heap, but we don't do that today. Because I'm concerned that the direct copy-to-parameter optimization could interfere with race-detector instrumentation (e.g., maybe the copies were previously necessary to ensure they're not clobbered by inserted raceread calls?), I've also added issue20780b.go to exercise this in a few different ways. Change-Id: I720598cb32b17518bc10a03e555620c0f25fd28d Reviewed-on: https://go-review.googlesource.com/c/go/+/281293 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Diffstat (limited to 'test/nilptr3.go')
-rw-r--r--test/nilptr3.go8
1 files changed, 0 insertions, 8 deletions
diff --git a/test/nilptr3.go b/test/nilptr3.go
index e0f2ed9767..3345cfa5ab 100644
--- a/test/nilptr3.go
+++ b/test/nilptr3.go
@@ -214,14 +214,6 @@ func p1() byte {
return p[5] // ERROR "removed nil check"
}
-// make sure not to do nil check for access of PAUTOHEAP
-//go:noinline
-func (p *Struct) m() {}
-func c1() {
- var x Struct
- func() { x.m() }() // ERROR "removed nil check"
-}
-
type SS struct {
x byte
}