Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
go version devel +2bf7034 Mon Apr 25 16:18:10 2016 +0000 darwin/amd64
What operating system and processor architecture are you using (go env)?
`````` darwin/amd64```
What did you do?
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.
f1 allocates and f2 doesn't. (You can tell just by looking at the generated assembly and see what the 3rd arg to convT2I is. If it is 0, then it allocates. If it is a pointer to a stack temp, it doesn't.)
With -m, we get (among other reports):
tmp3.go:6: sortable(a) escapes to heap
tmp3.go:10: f2 sortable(a) does not escape
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.
Please answer these questions before submitting your issue. Thanks!
go version
)?go version devel +2bf7034 Mon Apr 25 16:18:10 2016 +0000 darwin/amd64
go 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: