cmd/compile: avoidable construction of stack objects #43753
Comments
Slightly more realistic test case.
(Edit: Actually, it's an autotmp copy of |
Change https://golang.org/cl/284412 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Jan 18, 2021
…ng typecheck Currently, typecheck leaves arguments to OPANIC as their original type. This CL changes it to insert implicit OCONVIFACE operations to convert arguments to `interface{}` like how any other function call would be handled. No immediate benefits, other than getting to remove a tiny bit of special-case logic in order.go's handling of OPANICs. Instead, the generic code path for handling OCONVIFACE is used, if necessary. Longer term, this should be marginally helpful for #43753, as it reduces the number of cases where we need values to be addressable for runtime calls. However, this does require adding some hacks to appease existing tests: 1. We need yet another kludge in inline budgeting, to ensure that reflect.flag.mustBe stays inlinable for cmd/compile/internal/test's TestIntendedInlining. 2. Since the OCONVIFACE expressions are now being introduced during typecheck, they're now visible to escape analysis. So expressions like "panic(1)" are now seen as "panic(interface{}(1))", and escape analysis warns that the "interface{}(1)" escapes to the heap. These have always escaped to heap, just now we're accurately reporting about it. (Also, unfortunately fmt.go hides implicit conversions by default in diagnostics messages, so instead of reporting "interface{}(1) escapes to heap", it actually reports "1 escapes to heap", which is confusing. However, this confusing messaging also isn't new.) Change-Id: Icedf60e1d2e464e219441b8d1233a313770272af Reviewed-on: https://go-review.googlesource.com/c/go/+/284412 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Trust: Matthew Dempsky <mdempsky@google.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Compiling the program below with
-live
shows thatx
gets turned into a stack object:This is because the assignment
m[x.i] = true
passesx.i
by reference, causingx
to get marked as addrtaken.Note that the logically equivalent program that replaces
m[x.i] = true
withtmp := x.i; m[tmp] = true
does not create a stack object forx
.The text was updated successfully, but these errors were encountered: