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 loopdepth should reset when blocks end #22438

Open
mdempsky opened this issue Oct 25, 2017 · 6 comments
Open

cmd/compile: escape analysis loopdepth should reset when blocks end #22438

mdempsky opened this issue Oct 25, 2017 · 6 comments
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.
Milestone

Comments

@mdempsky
Copy link
Contributor

mdempsky commented Oct 25, 2017

Compiling the package below with compile -m shows that new(int) escapes to heap:

package p

func g() bool

//go:noescape
func h(*int)

func f() {
        var p *int
        if g() {
        x:
                goto x
        } else {
                p = new(int)
        }
        h(p)
}

After replacing x: goto x with for {}, it no longer escapes.

The issue is x is considered a looping label, so (*EscState).esc increments e.loopdepth when visiting it. However, loopdepth is never decremented again at the end of its enclosing block, so loopdepth is still incremented when visiting the p = new(int) assignment.

@mdempsky
Copy link
Contributor Author

A variation on the issue is:

func f() {
        var p *int
        {
        x:
                if g() {
                        goto x
                }
        }
        p = new(int)
        h(p)
}

This is trickier though, because we flatten blocks in the Node tree representation, so the above is indistinguishable from:

func f() {
        var p *int
x:
        if g() {
                goto x
        }
        p = new(int)
        h(p)
}

(Which also really needn't escape, but requires more sophisticated control flow analysis.)

@ianlancetaylor ianlancetaylor added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Mar 29, 2018
@ianlancetaylor ianlancetaylor added this to the Go1.11 milestone Mar 29, 2018
@ianlancetaylor
Copy link
Contributor

CC @dr2chase

@dr2chase
Copy link
Contributor

It seems aggressive to make this a milestone before we even have a non-test example of a loop made from a goto.

@ianlancetaylor
Copy link
Contributor

The milestone is to set a point by which we should make progress. If you want to make progress by changing the milestone to unplanned, that is fine.

@dr2chase dr2chase modified the milestones: Go1.11, Unplanned Mar 30, 2018
@dr2chase
Copy link
Contributor

Milestone set to unplanned, lacking any performance problem in "real" code caused by this shortfall (which would be a bit of a pain to fix since the tree-based analyses lack structural loop detectors).

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/193517 mentions this issue: cmd/compile: handle loopdepth in looping label

gopherbot pushed a commit that referenced this issue Sep 6, 2019
Add block method to preserve loop depth when evaluating statements in a
block, so escape analysis can handle looping label more precisely.

Updates #22438

Change-Id: I39b306544a6c0ee3fcbebbe0d0ee735cb71773e6
Reviewed-on: https://go-review.googlesource.com/c/go/+/193517
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 13, 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.
Projects
None yet
Development

No branches or pull requests

4 participants