https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98856
Alexander Monakov <amonakov at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amonakov at gcc dot gnu.org
--- Comment #38 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
Late to the party, but latency analysis of vpinsrq starting from comment #18 is
incorrect: its latency is different with respect to operands.
For example, on Zen 2 latency with respect to GPR operand is long (6 cycles,
one more that grp->xmm move latency), while latency with respect to XMM operand
is just one cycle, same as punpcklqdq. See uops.info, which also shows that
vpinsrq involves 2 uops, and it's easy to guess what they are: first uop is for
gpr->xmm inter-unit move (latency 5), and the second is SSE merge:
https://uops.info/html-instr/VPINSRQ_XMM_XMM_R64_I8.html
https://uops.info/html-instr/VMOVD_XMM_R32.html
So in the CPU backend there's not much difference between
movq
pinsrq
and
movq
movq
punpcklqdq
both have same uops and overall latency (1 + movq latency).
(though on Intel starting from Haswell pinsrq oddly has latency 2 w.r.t xmm
operand, but on Ice Lake it is again 1 cycle).
