cmd/compile: support inlining of functions containing function literals #28727
Comments
We do allocate function literals on the stack, if possible. |
The crux of this issue is that functions that contain closures aren't currently inlineable. If FuncA was inlined into BenchmarkTestA, then I expect escape analysis would detect that it can be stack allocated. |
Change https://golang.org/cl/267880 mentions this issue: |
Change https://golang.org/cl/283112 mentions this issue: |
…s with OCLOSURE I have exporting, importing, and inlining of functions with closures working in all cases (issue #28727). all.bash runs successfully without errors. Approach: - Write out the Func type, Dcls, ClosureVars, and Body when exporting an OCLOSURE. - When importing an OCLOSURE, read in the type, dcls, closure vars, and body, and then do roughly equivalent code to (*noder).funcLit - During inlining of a closure within inlined function, create new nodes for all params and local variables (including closure variables), so they can have a new Curfn and some other field values. Must substitute not only on the Nbody of the closure, but also the Type, Cvars, and Dcl fields. Fixes #28727 Change-Id: I4da1e2567c3fa31a5121afbe82dc4e5ee32b3170 Reviewed-on: https://go-review.googlesource.com/c/go/+/283112 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Trust: Dan Scales <danscales@google.com>
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Looking at the following benchmarks, returning a func literal always gets allocated on the heap while a similar approach using a struct can be allocated on the stack. I propose that func literals are also assessed whether they can be put on the stack or on the heap.
giving
When this func literal would be allocated on the stack, we would see a ~10x performance increase.
The text was updated successfully, but these errors were encountered: