cmd/compile: bad liveness map

[randall77]

package main

import "runtime"

func f(m map[int]int) {
outer:
        for i := 0; i < 10; i++ {
                for k := range m {
                        if k == 5 {
                                continue outer
                        }
                }
                runtime.GC()
                break
        }
        runtime.GC()
}

$ go tool compile -live tmp1.go
tmp1.go:5:18: live at entry to f: m
tmp1.go:8:12: live at call to mapiterinit: m .autotmp_4
tmp1.go:8:12: live at call to mapiternext: m .autotmp_4
tmp1.go:16:12: f: .autotmp_4 (type map.iter[int]int) is ambiguously live
tmp1.go:16:12: live at call to GC: .autotmp_4

The hiter for the inner loop (.autotmp_4) should not be live at the outer runtime.GC. It is live because liveness analysis sort of gives up on it (the "ambiguously live" comment there).
That's not so bad in and of itself; it's just imprecise.

But at the end of the inner loop we issue a VARKILL of .autotmp_4, so it definitely isn't live at the first runtime.GC (nothing with a pointer is live at that call, so it isn't even listed by -live). That means .autotmp_4 is live, then it isn't, then it is again. The first runtime.GC will free m, as nothing is holding m live at this point. The second runtime.GC finds m inside .autotmp_4 and tries to scan an already freed map. Boom.

This seems like a bad interaction between ambiguously live and VARKILL. Maybe fundamentally bad. Time to put my pondering cap on...

@aclements

[randall77]

1.9 for now. Likely will be promoted to 1.8.2.

[randall77]

Maybe VARKILL for ambiguously live variables should do an explicit zeroing?

[randall77]

Another fix would be to somehow get a VARKILL of the hiter at the "continue outer" statement. I'm not sure if that would be a complete fix. It's also hard to generate such a kill in order.go.

[randall77]

I hacked up a fix to explicitly zero at VARKILLs of ambiguously live variables.

The hack is definitely a hack. The challenge here is that we don't know a variable is ambiguously live until very late in compilation, after regalloc & friends. So, for example, we can't clobber any registers to do the zeroing. And it is after lowering, so we'd need to repeat the logic for each architecture. Maybe we could push liveness analysis (or at least ambiguity analysis) earlier, but I suspect that would be hard. Maybe VARKILL can clobber a few registers on architectures that need it.

It only triggers once during make.bash and once more during go test std (in (*Checker).caseTypes and TestMapSparseIterOrder, in case you were wondering) so I'm not worried about efficiency very much. Just something simple should be adequate.

I'll see if I can get a CL out tomorrow.

[randall77]

Reopening for 1.8.2 consideration.

[gopherbot]

CL https://golang.org/cl/41076 mentions this issue.