I think we should be careful doing this, at least when measuring the speed of operations that are only a couple of instructions:

1. This change makes the benchmark measure the latency of the operation rather than throughput which is a choice that may not be ideal for all the benchmarks. Floating point operations often have high latency but also high throughput due to pipelining. Which one we care more about is dependent on the application.

2. Making the input value dependent on the number of iterations the benchmark runs for (i.e. b.N) isn't ideal if the speed of the operation depends on said input value since it may lead to the benchmark speeding up or slowing down the longer it is run for. For example, the benchmark may end up in a steady state that happens to be an edge case where the operation is a no-op or unusually expensive.

One possible solution is to add a small array of input values (with a length of a power of 2 to avoid division instructions) and iterate over those for throughput benchmarks. The cost of the indexing and load should be low. Then add a separate latency benchmark for operations where we are particularly interested in latency (probably only the single instruction operations such as FMA, Sqrt, Abs, Copysign etc.).

This CL is probably the better solution, more robust as runtime.KeepAlive is basically guaranteed not to get optimizted out: https://go-review.googlesource.com/c/go/+/188437

If there's no boxing that happens with runtime.KeepAlive, then @nsajko's CL is probably a reasonable option. Especially because as @mundaym points out, we would have to first differentiate and duplicate the benchmarks based on the metric we care about (latency vs throughput), and then define additional input values for each of those benchmarks to avoid reaching a steady state. That seems like a lot of work for little return.