mov eax,2 / kmovw k1, eax being p0156 + p5. We could start with kxnor to generate a -1 and left-shift that, but that's 2 port5 uops vs. It's actually ok if the upper bytes of the vector are filled with broadcasts, not zeros, so we could use 0b1110 / 0b1100 etc. KSHIFT runs only on port 5 (SKX), but so does KMOV moving from integer registers would just cost extra instructions to set up integer regs first. Starting with k1 = 2 = 0b0010, we can init the rest with KSHIFT: _m128i combine64(long long a, long long b), rcx k4 =0b10000 3c latency The tune=haswell issue is maybe separate from the others, since gcc already knows that bouncing through memory isn't the optimal strategy. Or maybe use a hybrid strategy that does half with movd and half with store/reload, which can actually be better than either strategy alone on Bulldozer and SnB-family. Movd is about break-even on Bulldozer, better on SnB-family, much better on Core2/Nehalem, and significantly worse only on AMD K8/K10. Most of the text below is an attempt to back up this claim, but I don't have hardware to test with so all I can do is look at Agner Fog's tables and microarch pdf. I think it's better for a weighted-average of CPUs we care about for -mtune=generic. * -mtune=generic should probably favour movd/movq. All the reasons to favour store/reload on other AMD uarches are gone.) (Ryzen has 1 m-op movd/movq between vector and integer with 3c latency, shorter than store-forwarding. * -mtune=znver1 should definitely favour movd/movq instead of store/reload. * -mtune=haswell -mno-sse4 still uses one store/reload for _mm_set_epi64x. Gcc with -mtune=generic likes to bounce through memory when moving data from integer registers to xmm for things like _mm_set_epi32.

Amd k10 vs k8