In this example, converting a concrete value to an interface does not cause the integer value to be heap allocated:
fmt.Println(1000)
For that example, escape analysis currently marks the value as escaping to the heap due to the interface conversion and the call to fmt.Println (and all that happens inside Println), but walk later recognizes the value does not need to be heap allocated.
On the other hand, the integer value in the following interface conversion does get heap allocated because the optimization in walk is thwarted by the literal getting assigned to a local variable prior to use in the interface conversion:
v := 1000
fmt.Println(v)
We should be able to recognize this and get a similar result with those two cases. (This would be a follow up to Josh's work in #18704).
Separately, this slice can be stack allocated with a constant size (if it doesn't otherwise escape):
s := make([]int, 100)
But this slice is heap allocated because escape analysis treats it as having a non-constant size:
count := 100
s := make([]int, count)
We also should be able to recognize this.
The above scenarios might happen in a single function, but can also be the result of inlining one function into another.
We can hopefully handle this early in the compiler after inlining and devirtualization but before finalizing escape analysis results. Part of the solution can be using the new-ish ir.ReassignOracle.
I have a rough proof-of-concept that seems to hopefully handle cases similar to the ones above for basic literals and I plan to send a couple of CLs. The approach likely could be extended further. (I noticed this a while ago when working on #62653; there is some overlap with cases handled between that issue and this issue, though #62653 would be the broader solution for interface conversions).
Comment From: gabyhelp
Related Issues
- cmd/compile: improve escape analysis of make([]T, n) where n is non-constant #20533
- cmd/compile: avoid always escaping the receivers in interface method calls #62653
- cmd/compile: don't allocate when putting constant strings in an interface #18704 (closed)
- cmd/compile: some large-temp-heap-allocations need to be moved before escape analysis #10936
Related Code Changes
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)
Comment From: gopherbot
Change https://go.dev/cl/649077 mentions this issue: cmd/compile/internal/escape: propagate constants to make arguments
Comment From: gopherbot
Change https://go.dev/cl/649076 mentions this issue: cmd/compile/internal/escape: additional constant and zero-value tests plus debug logging
Comment From: gopherbot
Change https://go.dev/cl/649079 mentions this issue: cmd/compile/internal/escape: propagate constants to interface conversion arguments
Comment From: gopherbot
Change https://go.dev/cl/649555 mentions this issue: cmd/compile/internal/walk: convert composite literals to interfaces without allocating
Comment From: gopherbot
Change https://go.dev/cl/649078 mentions this issue: cmd/compile/internal/walk: use global zeroVal in interface conversions for zero values
Comment From: gopherbot
Change https://go.dev/cl/673795 mentions this issue: cmd/compile/internal/escape: use an ir.ReassignOracle
Comment From: gopherbot
Change https://go.dev/cl/676517 mentions this issue: cmd/compile/internal/walk: use original type for composite literals in addrTemp
Comment From: gopherbot
Change https://go.dev/cl/684116 mentions this issue: cmd/compile/internal/escape: evaluate any side effects when rewriting with literals
Comment From: gopherbot
Change https://go.dev/cl/675415 mentions this issue: cmd/compile/internal/escape: add debug hash for literal allocation optimizations
Comment From: gopherbot
Change https://go.dev/cl/684777 mentions this issue: cmd/compile/internal/escape: stop disabling literal allocation optimizations when coverage is enabled