cmd/compile: avoid allocs by better tracking of literals for interface conversions and make #71359
Labels
BugReport
Issues describing a possible bug in the Go implementation.
compiler/runtime
Issues related to the Go compiler and/or runtime.
Performance
Milestone
In this example, converting a concrete value to an interface does not cause the integer value to be heap allocated:
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:
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):
But this slice is heap allocated because escape analysis treats it as having a non-constant size:
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).
The text was updated successfully, but these errors were encountered: