https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82680
--- Comment #2 from Peter Cordes ---
gcc's sequence is *probably* good, as long as it uses xor / comisd / setcc and
not comisd / setcc / movzx (which gcc often likes to do for integer setcc).
(u)comisd and cmpeqsd both run on the FP add unit. Agner Fog doesn't list the
latency. (It's hard to measure, because you'd need to construct a round-trip
back to FP.) XOR-zeroing is as cheap as a NOP on Intel SnB-family, but uses an
execution port on AMD, so gcc's sequence is the same front-end uops but fewer
unfused-domain uops for the execution units on SnB. Also, the xor-zeroing is
off the critical path on all CPUs. (But ucomisd latency is probably as high as
cmpeqsd + movd).
Hmm, AMD bdver* and Ryzen take 2 uops for comisd, so for tune=generic it's
probably worth thinking about using ICC's sequence.
ICC's sequence is especially good if you're doing something with the integer
result that can optimize away the NEG. (e.g. use it with AND instead of a CMOV
to conditionally zero something, or AND it with another condition). Or if
you're storing the boolean result to memory, psrld $31, %xmm0 or PAND, then
movd directly to memory without going through integer regs.
comisd doesn't destroy either of its args, but cmpeqsd does (without AVX). If
you want both x and y afterwards (e.g. if they weren't equal, or you care about
-0.0 and +0.0 being different even though they compare equal), then comisd is a
win.
So I think we need to look at the choices given some more surrounding code.
I'll hopefully look at this some more soon.
