not that this matters at all, but:

func Dummy2(x uint64) int {
	if x == 0 {
		return 0
	}
	return bits.LeadingZeros64(x) - 63
}

(or 1 - bits.Len64(x).)

I don't know whether it's intentional that both 0 and 1 inputs yield 0. It's irrelevant to the optimization opportunity, though.

@TuomLarsen w.r.t. to SHRQ AX vs SHRQ $1, AX, they both encode to the same instruction. Am I missing something, or did you have in mind just the difference in the presentation?

@josharian SHRQ AX is encoded as 48d1e8 (the 1 implicit), whereas SHRQ $1, AX can also be encoded as 48c1e801. I'm not sure which one Go uses, that's why I commented on both.

Ah, I mistranslated the assembly when checking on the encoding and used the wrong width register. Sigh.

We should start generating the shorter version. I’m AFK—would you mind opening a new issue for this so that it can be tracked separately from re-using the flags result of the shift? Thanks. It’d actually make a decent starter issue for someone who wanted to contribute to SSA world, since we also make last minute encoding decisions in a similar way e.g. to use MOVL instead of MOVQ for small constants. cc @martisch

I've just checked and it seems that Go is indeed generating the shorter (implicit 1) version for the shift so I guess there is no need to open a separate issue. The disassembler says SHRQ $0x1, AX but the content of memory is 48d1e8.