Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/compile: not inlined closures can't inline inner closures #41988

Open
DmitriyMV opened this issue Oct 15, 2020 · 6 comments
Open

cmd/compile: not inlined closures can't inline inner closures #41988

DmitriyMV opened this issue Oct 15, 2020 · 6 comments
Assignees
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Performance
Milestone

Comments

@DmitriyMV
Copy link

DmitriyMV commented Oct 15, 2020

What version of Go are you using (go version)?

$ go version
go version go1.15 darwin/amd64

Does this issue reproduce with the latest release?

Yes.

What did you do?

Wrote code:

package go_closures

func callInt(val int) int {
	getInt := func() int { return val }
	return callFn(getInt)
}

func callFn(getInt func() int) int {
	outer := func() int { return getInt() }
	return globalFunc(outer)
}

var globalFunc = func(f func() int) int {
	return f()
}

What did you expect to see?

getInt is inlined into outer. outer escapes to the heap.

What did you see instead?

getInt isn't inlined into outer. Both outer and getInt escape to the heap.

@DmitriyMV
Copy link
Author

The main problem here is that getInt closure escapes when it can be folded into outer (even with call).

@mvdan mvdan added Performance NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Oct 15, 2020
@mdempsky
Copy link
Member

The issue here is we don't currently support inlining functions that contain closures. We'd first need to inline callFn into callInt to be able to inline getInt into outer.

Escape analysis is a red herring here. Escape analysis runs after inlining and doesn't affect inlining decisions.

@mdempsky
Copy link
Member

/cc @danscales , who's working on making functions that contain closures inlinable

@danscales
Copy link
Contributor

Yes, I will look at this bug, after I submit the base change that allows inlining of functions with closures.

@DmitriyMV
Copy link
Author

Still reproduces on 1.17:

package main

import (
	"fmt"
	"testing"
)

func callInt(val int) int {
	getInt := func() int { return val }
	return callFn(getInt)
}

func callFn(getInt func() int) int {
	outer := func() int { return getInt() }
	return globalFunc(outer)
}

var globalFunc = func(f func() int) int {
	return f()
}

func main() {
	result := testing.Benchmark(Bench)
	fmt.Println("result.AllocsPerOp()", result.AllocsPerOp())
}

func Bench(b *testing.B) {
	for i := 0; i < b.N; i++ {
		callInt(i)
	}
}

@danscales danscales self-assigned this Aug 17, 2021
@danscales
Copy link
Contributor

Thank you, will take a look if any improvement is possible for 1.18.

@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 13, 2022
@seankhliao seankhliao added this to the Unplanned milestone Aug 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Performance
Projects
Status: Triage Backlog
Development

No branches or pull requests

6 participants