cmd/compile: stores in infinite loops disappear

[randall77]

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]

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]

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

[mdempsky]

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]

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