@TocarIP @randall77

I don't think your test is actually measuring the multiply latency. It is only measuring multiply throughput.
If you chain the multiplies, so the next multiply needs the result of the previous one, then you're measuring latency and the rewrite we're using shows improvement.

package main

import "testing"

//go:noinline
func F1(n int) int {
	r := 0
	for i := 0; i < n; i++ {
		r += i * 15 // uses x<<4-x
	}
	return r
}

//go:noinline
func F2(n int) int {
	r := 0
	for i := 0; i < n; i++ {
		r += i * 19 // uses imul
	}
	return r
}

//go:noinline
func F3(n int) int {
	r := 1
	for i := 0; i < n; i++ {
		r *= 15 // uses x<<4-x
	}
	return r
}

//go:noinline
func F4(n int) int {
	r := 1
	for i := 0; i < n; i++ {
		r *= 19 // uses imul
	}
	return r
}

var sink int

func BenchmarkF1(b *testing.B) {
	for i := 0; i < b.N; i++ {
		sink = F1(1000)
	}
}

func BenchmarkF2(b *testing.B) {
	for i := 0; i < b.N; i++ {
		sink = F2(1000)
	}
}

func BenchmarkF3(b *testing.B) {
	for i := 0; i < b.N; i++ {
		sink = F3(1000)
	}
}
func BenchmarkF4(b *testing.B) {
	for i := 0; i < b.N; i++ {
		sink = F4(1000)
	}
}

BenchmarkF1-12    	 1000000	      1035 ns/op
BenchmarkF2-12    	 2000000	       809 ns/op
BenchmarkF3-12    	 3000000	       584 ns/op
BenchmarkF4-12    	 2000000	       897 ns/op

So when measuring throughput (F1 vs F2) the rewrite hurts, probably because we're substituting 3 instructions for 1. (Side note - why does this hurt? I would expect a reasonable fetch/retire engine to keep up with this loop.)

When measuring latency (F3 vs F4), however, the rewrite helps. We're now doing the multiply in two latency 1 instructions instead of 1 latency 3 instruction.

I think latency is more important than throughput, so we should keep the rewrite. I'm happy to hear arguments otherwise, though.

My processor is Intel(R) Xeon(R) CPU E5-1650 0 @ 3.20GHz, YMMV.

Ah, the reduction improves latency. Thanks for the explanation.

I think latency is more important than throughput, so we should keep the rewrite

Well, the other compilers I looked at (GCC, Clang, intel) seem, too, to optimize for latency, so I guess that's a point in favour of keeping those rewrites.

Ok, I'll close this issue then. Feel free to reopen if you want to continue discussing.