Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/compile: sync/atomic.SwapPointer arguments escape for the wrong reason #15283
In the implementation of sync/atomic.SwapPointer (which is in runtime/atomic_pointer.go), there's nothing that causes the "new" argument to escape, even though it needs to (because you could be swapping it in to a global). The compiler agrees:
However, you can't actually tickle this. For example, in principle the following program should sneak the address of stack variable y into a global variable:
But it doesn't!
This happens to work right now, but for the wrong reason: because SwapPointer is defined in the runtime and we use a "go:linkname" comment to expose it from sync/atomic, there's no escape information at all when the test program calls SwapPointer (hence the "passed to function[unknown]"), so the compiler conservatively assumes everything escapes. (In fact, the first argument doesn't have to escape and we have annotations in the runtime to that effect, but they never make it through.)
This all seems very fragile.
There weren't any tests to make sure these work correctly, and this led to escape analysis regressions in both linux/s390x and js/wasm. The underlying issue that cmd/compile is only getting some of these correct because escape analysis doesn't understand //go:linkname is still present, but at least this addresses the fragility aspect. Updates #15283. Change-Id: I546aee1899d098b2e3de45e9b33c3ca22de485f8 Reviewed-on: https://go-review.googlesource.com/c/go/+/172420 Run-TryBot: Matthew Dempsky <firstname.lastname@example.org> TryBot-Result: Gobot Gobot <email@example.com> Reviewed-by: Austin Clements <firstname.lastname@example.org>