The SSA backend performs common subexpression elimination much better than older versions of go. Can you check the resulting binary size? For example, I get a 62x smaller object file from tip with your example (go tool compile slow.go):

Wrapping slow.go in a main, I get an overall 11x size decrease:

Compiling with today's tip, I not only confirm tzneal's numbers, but the compile-time regression seems gone (!). It's even faster than 1.6 for me. @tzneal would you mind double checking before I close this bug?

Fixed by 11a8086, dup of #14781 perhaps?

Or the turning off of SSA consistency checks in 5305a32?

I get the same results (slightly faster than 1.6 now). The original slowdown showed up even with check disabled, but the speedup doesn't appear to be related to @josharian's change. I reverted it, and it was still faster.

Anyone want to bisect?

I'll bisect.

I believe that 7c18f8c is the commit in question.

That said, I can't quite reproduce the timings that others have given here. The bad case isn't as bad, and tip is slower for me than 1.6.

(These are run with -gcflags '-ssa=1 -d=ssa/check/off' where appropriate. Numbers are average of 5 runs.)

So tip is still roughly 25% slower than 1.6 for me. I'm on linux/amd64.

I also looked into which commits were responsible for the size reductions.

a0232ea reduced the size from 20M to 320K.

3648d2d gave another 50% reduction to 164K.

Good work @josharian and @skohanim!

Ok, not quite back to parity but pretty close. The object size is way smaller which will probably speed up the linker enough to reach parity. I'm going to close as "fixed enough".