Unfortunately the go1 benchmark shows no improvement with such optimization.

(Mul16 x y) -> (MULBB x y)
(ADD z (MULBB x y) -> MULABB(x y z)
(SUB z (MUL x y) -> MULS(x y z)

go1 benchmarks (or any benchmark, really) aren't always useful. Their performance is a useful signal when:

1. You think your change should make them faster, and it doesn't.
2. You think your change should not make them slower, and it does.

For instance, I suspect the go1 benchmarks never do a 16-bit multiply. So only number 2 is in play.

If you have an optimization you think is useful but doesn't affect the go1 benchmarks, write your own benchmark which is helped by your change.

1. MULBB, MULABB
2. MULS
3. MMUL, MMULA, MMULS

Try them again in Go1.10.

Please also change milestone to go1.10

4. MULAF, MULSF, MULAD, MULSD // float point version MLA/MLS

MULBB/MULABB have no improvement compared to MUL/MULA.

Change https://golang.org/cl/61150 mentions this issue: cmd/compile: optimize ARM code with efficient FP instructions

MULAF, MULSF, MULAD, MULSD did not always improve code quality, since
they required resultInArg0 set to true. So they benefited
a = a + b * c
but not
a = b + c * d especially b was still in use.