cmd/compile: internal compiler error: schedule does not include all values in block on s390x

[ALTree]

$ gotip version
go version devel +cacac8bdc5 Tue Jun 9 02:49:06 2020 +0000 linux/amd64

The following program:

package p

func f() bool {
	var c float64
	c = 0
	c = -c + 1
	return (c != 0) == (c != 0)
}

Crashes the tip compiler when built for s390x with optimizations disabled:

$ GOARCH=s390x gotip tool compile -N crash.go

crash.go:7:27: internal compiler error: 'f': schedule does not include all values in block b1
goroutine 1 [running]:
runtime/debug.Stack(0xd4bb80, 0xc00000e018, 0x0)
	/home/alberto/go/src/runtime/debug/stack.go:24 +0x9f
cmd/compile/internal/gc.Fatalf(0xc00001a300, 0x36, 0xc0003cb920, 0x2, 0x2)
	/home/alberto/go/src/cmd/compile/internal/gc/subr.go:199 +0x1b0
cmd/compile/internal/gc.(*ssafn).Fatalf(0xc000011d10, 0x71b100000002, 0xc63c80, 0x30, 0xc000046b10, 0x1, 0x1)
	/home/alberto/go/src/cmd/compile/internal/gc/ssa.go:6844 +0x1a5
cmd/compile/internal/ssa.(*Func).Fatalf(...)
	/home/alberto/go/src/cmd/compile/internal/ssa/func.go:625
cmd/compile/internal/ssa.schedule(0xc00013c420)
	/home/alberto/go/src/cmd/compile/internal/ssa/schedule.go:306 +0x1baa
cmd/compile/internal/ssa.Compile(0xc00013c420)
	/home/alberto/go/src/cmd/compile/internal/ssa/compile.go:93 +0x9d1
cmd/compile/internal/gc.buildssa(0xc00013c2c0, 0x0, 0x0)
	/home/alberto/go/src/cmd/compile/internal/gc/ssa.go:460 +0xd25
cmd/compile/internal/gc.compileSSA(0xc00013c2c0, 0x0)
	/home/alberto/go/src/cmd/compile/internal/gc/pgen.go:317 +0x5d
cmd/compile/internal/gc.compile(0xc00013c2c0)
	/home/alberto/go/src/cmd/compile/internal/gc/pgen.go:275 +0x345
cmd/compile/internal/gc.funccompile(0xc00013c2c0)
	/home/alberto/go/src/cmd/compile/internal/gc/pgen.go:220 +0xc5
cmd/compile/internal/gc.Main(0xc6e560)
	/home/alberto/go/src/cmd/compile/internal/gc/main.go:747 +0x344f
main.main()
	/home/alberto/go/src/cmd/compile/main.go:52 +0xb1

It compiles fine on go1.14.4, so this is a tip regression. I'm tentatively labelling this as a release-blocker, but leaving to you to decide if this is fine.

cc @mundaym @randall77 @cherrymui

[mariecurried]

Bisection points to b2790a2

[mundaym]

Slightly more minimal reproducer:

package p

func f(x float64) bool {
	x += 1
	return (x != 0) == (x != 0)
}

The problem is that the s390x rules can insert duplicate Select0 and Select1 ops. For example, these rules (added for Go 1.15 in b2790a2) insert Select1 ops:

(LTDBR (Select0 x:(F(ADD|SUB) _ _)))   && b == x.Block -> (Select1 x)
(LTEBR (Select0 x:(F(ADDS|SUBS) _ _))) && b == x.Block -> (Select1 x)

That isn't a problem with CSE enabled because it will de-duplicate them. One possibility is that we pull the Select0 and Select1 de-duplication code that currently exists in CSE into a separate, mandatory, pass. I'll send that as a CL.

[gopherbot]

Change https://golang.org/cl/237118 mentions this issue: cmd/compile: always tighten and de-duplicate tuple selectors

[beoran]

@mundaym As you stated "The problem is that the s390x rules can insert duplicate Select0 and Select1 ops.". I may be out of line here, but I'd say the right fix is to avoid doing that in the first place, not add another pass that cleans up the mistake from the previous pass.

[mundaym]

@beoran Yeah, that is one possibility. Though I would point out that there is no good way to have tuple optimization rules without encountering the duplication issue and it may well be hit again in the future.

The main advantage of doing the cleanup as a separate pass is however that it means that none of the passes up until that point have to worry about maintaining this invariant, whether it be CSE, optimization rules or some other future optimization pass that has yet to be added. That's quite nice since every invariant like this that we have to maintain is yet more complexity in individual passes. There is no real reason to treat selectors differently from other ops in most passes, only the scheduler & register allocator actually care.

[beoran]

Seeing the PR and the relative simplicity of this pass, I must admit this is probably an ok solution. I didn't know the GC go compiler had that many mandatory passes, so one more might be ok, if it simplifies other passes. Op wo 10 jun. 2020 16:56 schreef GopherBot <notifications@github.com>:

…

Closed #39472 <#39472> via ac743de <ac743de> . — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#39472 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAARM6JQPCXAWBKM3LKBYK3RV6NJNANCNFSM4NZFXYDA> .