cmd/compile: investigate test/fixedbugs/issue20250.go with GOEXPERIMENT=unified #54402
Description
test/fixedbugs/issue20250.go contains this ERROR expectation:
go/test/fixedbugs/issue20250.go
Line 19 in f469f20
This works fine currently on all trybots. It also works fine currently with GOEXPERIMENT=unified on most trybots.
But with GOEXPERIMENT=unified and the linux-arm and js-wasm trybots, we instead report:
live at entry to f.func1: &e a
on that line. Note: &e a instead of a &e.
Semantically, this doesn't matter. But it's still odd.
Notably, unified IR is generating identical IR for linux-amd64, linux-arm, and js-wasm:
diff -u <(GOEXPERIMENT=unified GOOS=linux GOARCH=amd64 go tool compile -l -W=2 issue20250.go) <(GOEXPERIMENT=unified GOOS=linux GOARCH=arm go tool compile -l -W=2 issue20250.go)
diff -u <(GOEXPERIMENT=unified GOOS=linux GOARCH=amd64 go tool compile -l -W=2 issue20250.go) <(GOEXPERIMENT=unified GOOS=js GOARCH=wasm go tool compile -l -W=2 issue20250.go)
so it's odd linux-arm and js-wasm are different.
Compiling for all targets listed by go tool dist list, it looks like it's dependent upon GOARCH:
- Team
a &e: amd64, arm64, ppc64, ppc64le, riscv64 - Team
&e a: 386, arm, loong64, mips64, mips64le, s390x, wasm
I thought maybe this is regabi vs no-regabi architectures, but adding noregabi to GOEXPERIMENT only causes riscv64 to switch sides. The distinction between (e.g.,) amd64 and arm remains.
I plan to just relax the test expectations to allow either a &e or &e a, because I don't think it's a real issue and its blocking enabling GOEXPERIMENT=unified by default. But filing an issue to remember to look into this further into the dev cycle.