This benchmark, shows the cliff when values pass the upper limit of DUFFCOPY

http://paste.ubuntu.com/10762232/

root@labs-782e8a:~/src/duffbench# go test -bench=.                                                                                                                        
testing: warning: no tests to run
PASS
BenchmarkCopy1          300000000                3.89 ns/op
BenchmarkCopy4          50000000                40.0 ns/op
BenchmarkCopy16         20000000                77.5 ns/op
BenchmarkCopy32         20000000               139 ns/op
BenchmarkCopy64          5000000               255 ns/op
BenchmarkCopy128         3000000               538 ns/op
BenchmarkCopy129         3000000               745 ns/op   <<<<
BenchmarkCopy256         2000000              1088 ns/op

6g and 8g use REP with MOVSL/MOVSQ, which I believe @randall77 determined to be faster around that threshold. I would believe that the other architectures could benefit from a call to memmove or something similar. (This is a place where NEON should shine.)

[Please don't use { } syntax in bug headings. It doesn't sort well.]

This may apply to some subset of the non-x86 systems.
The x86 systems are doing the right thing.

538->745 is hardly a "cliff". I'm surprised it is so close given the lack of anyone tuning this mechanism on arm. (Or did I miss someone doing that?)

minux is right, the moves generated here are sometimes used to marshal arguments to a function, so we can't call a function to do the marshaling. For other situations like your a=b example you could call memmove. It might take some work to distinguish those two cases, however. At the move generation point the marshaling has already been turned into a=b assignments.