I did a comparison of the write barriers produced when compiling cmd/compile with and without SSA. Sometimes it generates dramatically more write barriers than the old backend. Here are the top movers:

+235 cmd/internal/obj/ppc64.buildop(SB)
+72 cmd/internal/obj/mips.buildop(SB)
+55 cmd/internal/obj/arm.buildop(SB)
+14 cmd/compile/internal/amd64.ssaGenBlock(SB)
+10 cmd/compile/internal/ssa.rewriteValuegeneric_OpStructSelect(SB)
+9 cmd/compile/internal/ssa.decomposeBuiltIn(SB)
+8 cmd/compile/internal/ssa.nilcheckelim(SB)
+6 runtime.getitab(SB)
+5 runtime.(_TypeAssertionError).Error(SB)
+4 runtime.assertI2T(SB)
+4 reflect.Value.MapKeys(SB)
+4 fmt.(_pp).printReflectValue(SB)
+4 cmd/compile/internal/ssa.(_Value).LongString(SB)
+4 cmd/compile/internal/ssa.(_edgeState).setup(SB)
+3 runtime.assertE2T(SB)
+3 reflect.(*structType).FieldByNameFunc(SB)
+3 cmd/internal/obj.Linknew(SB)
+3 cmd/compile/internal/gc.typecheck1(SB)
+3 cmd/compile/internal/gc.Main(SB)

I looked into a few of these and it looks like the old backend is generating one call to typedmemmove in cases where SSA is generating a huge number of calls to writebarrierptr. In the smaller movers like runtime.getitab this may actually be the right thing; if there are just a few pointers, writebarrierptr is better. But 235 more write barriers is probably not the right thing.

This was generated with the following script:

#!/bin/bash

awk '
function dump() {
  if (fn != "")
    counts[fn][file] = n
}
/^TEXT/ { dump(); fn=$2; n=0 }
/CALL runtime.writebarrierptr/ { n++ }
END {
  dump();
  for (fn in counts) {
    printf("%+d %s\n", counts[fn]["b"] - counts[fn]["a"], fn)
  }
}
' file=a <(go tool objdump "$1") file=b <(go tool objdump "$2") | sort -gr

/cc @khr @dr2chase