Also, why isn't the ssa check builder isn't failing with this? Maybe... umm.. @dmitshur knows?

I think the SSA check builder only runs for AMD64. It doesn't do cross compilations.

Running with the SSA checker on shouldn't impact the generated code (I thought?).

I also thought so. But then I found this
https://go.googlesource.com/go/+/refs/heads/master/src/cmd/compile/internal/ssa/compile.go#80

My guess is that it might catch a real bug that we (accidentally) depended on value ordering.

Change https://golang.org/cl/216379 mentions this issue: cmd/compile: on PPC64, fold offset into some loads/stores only when offset is 4-aligned

CL https://go-review.googlesource.com/c/go/+/216379 should fix the immediate problem.

When SSA check is on, the Values are reordered, which affects the ordering of rewriting rules firing (and eventually whether some rules are fired or not), which affects the compilation result.

Thanks, @cherrymui! (Although it's going to cause me a bunch of rebase pain. No good deed goes unpunished. :P)

We should probably find some way to run with SSA check on for all architectures, somewhere.

And IMHO, it'd be good to use different random seeds for different runs, to get better coverage. I now remember having that discussion with Keith when the CL first went by.

Filed #36756 for the builder and sent https://go-review.googlesource.com/c/go/+/216418 for the seed randomization.

Tests in cmd/compile/internal/gc/ssa_test.go are run with SSA check enabled (on each host architecture). It covers basic operations but is not as complete as building std.

cc @laboger