cmd/compile: unexplained allocation for convT2I #15451
Comments
With So I think this has something to do with the analysis. Maybe because quickSort is recursive and escape analysis gives up? |
|
Was just looking at this, decided (in the process) that the explainer (-m -m) could use a bit more work (did not finger the call properly for the escape at line 28 -- it is to Sort). And the short answer is "you passed the interface to Sort, and Sort was recorded as escUnknown, so it escaped". The longer answer is "and Sort contains a call to quickSort which is recursive, and escape analysis punts on recursive functions, and thought I did work on a CL for not punting, it was very, very fragile and did not produce much benefit, so I let it get pretty stale". I will try to revive that CL and see if it helps here at all -- if it does, that raises its priority, and if not, then not. |
|
Did a bit more work and brought the recursive-function-nest-escape-analyzer forward, and that by itself was not enough. |
josharian
changed the title
gopherbot
added
the
compiler/runtime
Wow, this was fun to find. It looks like anything passed to sort.Sort is thought of as escaping to the heap - golang/go#15451. There's an easy fix for this which is to allocate the struct in global context; since everything is single-threaded no issues with this. We may be able to use sort.Slice() to avoid this weirdness entirely.
Wow, this was fun to find. It looks like anything passed to sort.Sort is thought of as escaping to the heap - golang/go#15451. There's an easy fix for this which is to allocate the struct in global context; since everything is single-threaded no issues with this. We may be able to use sort.Slice() to avoid this weirdness entirely.
Wow, this was fun to find. It looks like anything passed to sort.Sort is thought of as escaping to the heap - golang/go#15451. There's an easy fix for this which is to allocate the struct in global context; since everything is single-threaded no issues with this. I looked a little bit at using sort.Slice(); we can't use this because we want to sort one array based on the other. After the first swaps happen in the original array the moveScore array gets out of sync. This was a leftover from using a priority queue for the sorting interface.
Wow, this was fun to find. It looks like anything passed to sort.Sort is thought of as escaping to the heap - golang/go#15451. There's an easy fix for this which is to allocate the struct in global context; since everything is single-threaded no issues with this. I looked a little bit at using sort.Slice(); we can't use this because we want to sort one array based on the other. After the first swaps happen in the original array the moveScore array gets out of sync. This was a leftover from using a priority queue for the sorting interface.
Please answer these questions before submitting your issue. Thanks!
go version)?go version devel +2bf7034 Mon Apr 25 16:18:10 2016 +0000 darwin/amd64go env)?`````` darwin/amd64```
See attached typescript. I do not understand why line 28, the call to sort.Sort, is allocating. It is in a call to convT2I but a, a.r, and the slice a.r[i] points to are already on the heap. It seems like escape analysis and/or optimizations are missing a chance to avoid an allocation.
The text was updated successfully, but these errors were encountered: