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: escape analysis does not analyze closure calls #7714

Closed
randall77 opened this Issue Apr 4, 2014 · 10 comments

Comments

Projects
None yet
9 participants
@randall77
Copy link
Contributor

randall77 commented Apr 4, 2014

func set(p *int, x int) {
    *p = x
}
func main() {
    var y int
    set(&y, 42)
}

escape analysis works, y is allocated on the stack.

func main() {
    var y int
    func(p *int, x int) {
        *p = x
    }(&y, 42)
}

escape analysis gives up, y is allocated on the heap.  There's no difference between the
two codes except that the set function is declared separately in the first case and
anonymously in the second.
@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

ianlancetaylor commented May 9, 2014

Comment 1:

Labels changed: added repo-main.

@rsc

This comment has been minimized.

Copy link
Contributor

rsc commented Sep 15, 2014

Comment 2:

Labels changed: added release-none, removed release-go1.4.

Status changed to Accepted.

@dvyukov

This comment has been minimized.

Copy link
Member

dvyukov commented Feb 11, 2015

Similar case from #8615

x := 0
defer func(p *int) {
    *p = 1
}(&x)

@dvyukov dvyukov changed the title cmd/gc: escape analysis too conservative cmd/gc: escape analysis does not analyze closure calls Feb 11, 2015

@rsc rsc added this to the Unplanned milestone Apr 10, 2015

@rsc rsc removed release-none labels Apr 10, 2015

@rsc rsc changed the title cmd/gc: escape analysis does not analyze closure calls cmd/compile: escape analysis does not analyze closure calls Jun 8, 2015

@pmalek

This comment has been minimized.

Copy link

pmalek commented Sep 3, 2017

What is the current status of this?

Go 1.9 still moves x to heap in this snippet:

package main

func main() {
	x := 0
	func(p *int) {
		*p = 1
	}(&x)
}

build output:

go build -gcflags=-m main.go
# command-line-arguments
./main.go:5:2: can inline main.func1
./main.go:7:4: &x escapes to heap
./main.go:4:7: moved to heap: x
./main.go:5:2: main func literal does not escape
./main.go:5:10: main.func1 p does not escape
@randall77

This comment has been minimized.

Copy link
Contributor Author

randall77 commented Sep 3, 2017

This has not been fixed. And as far as I know, no one is working on it.
We don't have enough people to get to every optimization idea, unfortunately.

@openex27

This comment has been minimized.

Copy link

openex27 commented Apr 13, 2018

Dose the current Go1.10 version fix this?

code:

package main

func main() {
    var y int
    func(p *int) {
        *p = 1
    }(&y)
}

go build -gcflags=-m x.go output:

./x.go:5:5: can inline main.func1
./x.go:7:6: inlining call to main.func1
./x.go:7:7: main &y does not escape

@agnivade

This comment has been minimized.

Copy link
Member

agnivade commented Apr 13, 2018

Yes, seems like that. Maybe a side-effect of some other optimization. ping @randall77, @josharian

@mvdan

This comment has been minimized.

Copy link
Member

mvdan commented Apr 13, 2018

The simple versions were done by @huguesb, I believe, such as c4b65fa. It's not clear to me whether all the cases are done, or if this issue should be kept open.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

ianlancetaylor commented Mar 29, 2019

I think this is still an issue. In the simple example it doesn't happen because the call is inlined, but you can see it if you "go build" with -gcflags=-l to disable inlining.

@mdempsky

This comment has been minimized.

Copy link
Member

mdempsky commented Apr 16, 2019

These are fixed with -newescape=true, and confirmed with updated regress tests.

@mdempsky mdempsky closed this Apr 16, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.