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).