cmd/compile: missed escape analysis opportunity #5919
Comments
Well, it's not that simple. The escape analysis has to keep track of when pointers at flowing from a location to another. But it should notice that the string itself does not escape, only the data pointed to by the string. A special case could be added for strings, but it would not solve the general issue, which that the level of indirection of escaping must be remembered. It's weird because I thought rsc said it was working properly when inside a single package. |
It may be okay to special case assignment of something to itself, to handle reslicing.
The change would not be safe in general:
func f(s, t *string) {
*t = *s
}
In that function, s (well its internal pointer) really does escape (into t).
Labels changed: added priority-later, go1.2maybe, removed priority-triage. Status changed to Accepted. |
rsc
changed the title
|
/cc @rsc @dr2chase @randall77, currently running https://play.golang.org/p/JU4Y50K7ne on tip Go1.8 ac05542 says otherwise, PTAL and help correct me if am mistaken. $ cat main.go && go tool compile -l -m main.go
package main
func main() {
var name = "gopher"
f(&name)
var nameCopy string
g(&name, &nameCopy)
var a, b int
a = 10
h(&a, &b)
i(&b)
}
func i(a *int) {
*a = *a
}
func h(i, j *int) {
*j = *i
}
func g(s, t *string) {
*t = *s
}
func f(s *string) {
*s = *s
}
main.go:28: leaking param content: s
main.go:24: leaking param content: s
main.go:24: g t does not escape
main.go:20: h i does not escape
main.go:20: h j does not escape
main.go:16: i a does not escape
main.go:5: main &name does not escape
main.go:8: main &name does not escape
main.go:8: main &nameCopy does not escape
main.go:12: main &a does not escape
main.go:12: main &b does not escape
main.go:13: main &b does not escape
$ go version
go version devel +ac05542 Wed Jan 11 01:39:54 2017 +0000 darwin/amd64 |
|
@odeke-em If I'm not mistaken, what's going on there is that the pointers don't escape, and strings are always heap-allocated (so nothing's printed out about them escaping). But it seems what the original report was really concerned about was a reslicing function, and I believe that doesn't escape as of Go 1.8. The two indicated lines are what I believe show that the reslicing function doesn't cause its underlying slice to escape. I'm not confident enough in my reading of the |
|
I think the important part of that output are these missing lines: Those are the root of the inference chain. The latter is used to derive the :22 message about the initializer of I think we should still leave this bug open though. For this function: we do get a |
|
Change https://golang.org/cl/136496 mentions this issue: |
seankhliao
added
the
NeedsInvestigation
Escape analysis says that s escapes in this function even though it doesn't: func f(s *string) { *s = *s } If f is called as f(&s), the compiler will (with inlining disabled) allocate s on the heap even though it could be allocated on the stack. For types that don't contain pointers, this doesn't happen. For example, if I change string to int, the parameter isn't considered to escape. A real-world example of when this might happen is when a function takes a pointer to a string or slice and then re-slices it: *s = (*s)[n:]The text was updated successfully, but these errors were encountered: