You are not using the value from popcnt2, and because the function was inlined, the compiler can see the value is unused, so it removed the call entirely.

Here is something I wrote about writing a reliable benchmark, http://dave.cheney.net/2013/06/30/how-to-write-benchmarks-in-go, hopefully it will be of use.

I am going to close this as this is not a bug. For general Go questions see https://golang.org/wiki/Questions. Thanks!

Huh, I've seen the _ = f(x) and even simple f(x) idiom in some Go benchmarks I've encountered here and there, and it worked. But apparently with SSA they're going to become useless benchmarks.

Using the top-level result variable solves the problem. I guess it's kind of a documentation issue. Either way, thank you as well.

@bradfitz I think we should reopen this issue, or replace it with another as a placeholder to double check that all the benchmarks in the stdlib are armoured against the improving abilities of the SSA backend.

I've found a few cases of _ = f(x) in the stdlib using [the search](https://golang.org/search?q=%28?s%29for i := 0%3B i < b.N%3B i%2B%2B+{.\s%2B_ =), but all of them seem to be unaffected by the SSA so far.

Could the problem be solved with something similar to //go:noinline magic comment (//go:noremove)? Code emitted by go test for benchmarks could be marked that way to make sure the compiler won't remove the code inside the loop.

No, no more magical //go:XXX comments please.
Just add a global variable to sink the values.

It's beginning to sound like gcc's attribute,
and I really don't want to read Go programs like
this:

//go:do_not_optimize_this
for i := 0; i < 10; i++ {}
//go:unroll 10
for i := 0; i < 100; i++ {
f(i) //go:must_inline
}

One major issue with this benchmark is that it uses the loop's index as an argument to the function. See the "Traps for young players" in this article: https://dave.cheney.net/2013/06/30/how-to-write-benchmarks-in-go.