cmd/compile: improve escape analysis fidelity #33981
Labels
Milestone
Comments
mdempsky
added
the
NeedsFix
|
Change https://golang.org/cl/193178 mentions this issue: |
|
Change https://golang.org/cl/193177 mentions this issue: |
|
Change https://golang.org/cl/193179 mentions this issue: |
|
A little disappointing, but it looks like this only really helps cmd/compile/internal/gc.substArgTypes; in particular, the ... argument no longer escapes to the heap. So the ~30 call sites all benefit. This is because the improved fidelity for cmd/compile/internal/types.SubstAny (used by gc.substArgTypes) can now report that for the It also allows a few maps to be stack allocated in pprof: |
|
Building all of Kubernetes (go build k8s.io/kubernetes/...) yields slightly better results; 145 improvements in total. 145 escape analysis improvements |
gopherbot
pushed a commit
that referenced
this issue
Sep 10, 2019
No behavior change; just inverting the loop ordering so the per-parameter behavior is a bit clearer. Passes toolstash-check. Updates #33981. Change-Id: I9bfcd7d0a4aff65a27ced157767ca2ba8038319a Reviewed-on: https://go-review.googlesource.com/c/go/+/193177 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
gopherbot
pushed a commit
that referenced
this issue
Sep 10, 2019
This CL moves parameter tagging to before escape analysis is complete, so we still have access to EscLocation. This will be useful once EscLocation starts tracking higher-fidelity escape details. Notably, this CL stops using n.Esc to record parameter escape analysis details. Now escape analysis only ever sets n.Esc to EscNone or EscHeap. (It still defaults to EscUnknown, and is set to EscNever in some places though.) Passes toolstash-check. Updates #33981. Change-Id: I50a91ea1e38c442092de6cd14e20b211f8f818c9 Reviewed-on: https://go-review.googlesource.com/c/go/+/193178 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
|
Change https://golang.org/cl/197679 mentions this issue: |
|
Change https://golang.org/cl/197680 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Oct 7, 2019
This CL better abstracts away the parameter leak info that was directly encoded into the uint16 value. Followup CL will rewrite the implementation. Passes toolstash-check. Updates #33981. Change-Id: I27f81d26f5dd2d85f5b0e5250ca529819a1f11c2 Reviewed-on: https://go-review.googlesource.com/c/go/+/197679 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Currently, when compiling the test case below, escape analysis decides that both
iandjescape and need to be heap allocated. However, actually onlyiescapes;jis safe to stack allocate.The reason for this is that the escape analysis tags use a single-bit flag
EscContentEscapesto mark if anything pointed to by a parameter escape to the heap; so callers can't distinguishg = **pfromg = *p.Contrast with how
escapeReturnEncodinguses multiple bits to store a fixnum value, so it can distinguishreturn p,return *p,return **p, etc.Moreover, while we currently track these values in a
uint16during escape analysis, they're eventually converted to strings and serialized in export data as strings, so the 16-bits constrained is self-imposed.The text was updated successfully, but these errors were encountered: