/ go Public
cmd/compile: better escape analysis of
Issues related to the Go compiler and/or runtime.
The path to resolution is known, but the work has not been done.
@aclements points out 3 cases that escape analysis could be better at:
This currently forces
bufto the heap, because the
pStr.Data = uintptr(unsafe.Pointer(&buf))assignment is treated as
(*pStr).Data = unsafe.Pointer(&buf)and assignments through a pointer indirection are currently always treated as escaping to the heap.
This could be improved if we noticed during escape analysis that
pStralways points to
str. Then instead of flowing to the heap,
&bufcould just flow to
strdirectly. Consequently, the function should overall analyze to "parameter
~r0" instead of "leaks to heap".
In this case,
strconv.Atoidoesn't leak its string argument anywhere, so we should be able to pretty easily recognize that the
OBYTES2STRargument can be safely promoted to
Similar to 2 above, if we recognize that
bufis never reused after its conversion to
string, we should be able to directly reuse the byte array memory for the
stringwithout copying. On dev.regabi, closure analysis (i.e., deciding whether to capture variables by value or reference) is now part of escape analysis, and it seems reasonable to extend it to handle this use case as well.
We'd need to recognize that operations like
string(buf[:])are logically copying
bufby value, rather than taking a reference to it.
The text was updated successfully, but these errors were encountered: