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: stores in infinite loops disappear #15635

Closed
randall77 opened this issue May 10, 2016 · 4 comments
Closed

cmd/compile: stores in infinite loops disappear #15635

randall77 opened this issue May 10, 2016 · 4 comments

Comments

@randall77
Copy link
Contributor

func f(p *int) {
    _ = *p // nil check
    for i := 0; true; i++ {
        *p = i
    }
}

With SSA, this compiles to:

    0x0000 00000 (infloop.go:4) MOVQ    "".p+8(FP), AX
    0x0005 00005 (infloop.go:4) TESTB   AL, (AX)
    0x0007 00007 (infloop.go:5) JMP 7

There are no reads of memory in the loop, so the entire store chain gets optimized away.

Is this a problem? I'm not sure. It is unexpected (at least, to me) so it may be worth fixing. Opinions? @rsc @josharian @griesemer @mdempsky @dr2chase @ianlancetaylor

This issue may prevent the optimization described in #15631 (treating calls just like stores). We definitely don't want calls vanishing.

@griesemer
Copy link
Contributor

It's only observable if we have another goroutine watching that variable (*p). But for another goroutine to see the actual variable, Go requires some communication between the goroutines (sync or channel send). So it might be permissible to do nothing.

@randall77
Copy link
Contributor Author

FWIW, gcc -O1 and above also drop the writes from the equivalent C code.

@mdempsky
Copy link
Member

Agreed with @griesemer that the Go spec + memory model allow this optimization. The loop never terminates and doesn't have any synchronization events, so there's no way for another goroutine to guarantee any of the *p = i assignments have happened.

@randall77
Copy link
Contributor Author

Ok, sounds like this is allowed. I'll close.

@golang golang locked and limited conversation to collaborators May 13, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants