3 ms·

> Indeed, AVX2 has a bit of a quirk where regular registers (%rax and the like) cannot directly be transfered to the SIMD ones with a MOV; it must go through RA

by nkurz 7y ago

> Indeed, AVX2 has a bit of a quirk where regular registers (%rax and the like) cannot directly be transfered to the SIMD ones with a MOV; it must go through RAM (typically the stack), which costs both latency and two CPU instructions (MOV to the stack, VMOV from the stack). I don't think this is quite correct. You can move efficiently from r64 to XMM/YMM without going through memory with MOVQ/_mm_cvtsi64_si128. I'm not able to look into it more closely right now, but these links should give insight: https://www.felixcloutier.com/x86/movd:movq https://www.felixcloutier.com/x86/movd:movq https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=movq&expand=1885 https://software.intel.com/sites/landingpage/IntrinsicsGuide... My vague recollection is that you might be right that this is clumsy with AVX2. Maybe it's a case where you have to take advantage of the fact that XMM1 and YMM1 are same register, and cast the YMM to XMM? Or just drop to inline assembly. But thanks for the writeup, and I hope to be able to look at Shishua more closely at some point in the future.

BeeOnRope 7y ago
Yes, most instructions that modify only the bottom element(s) didn't get a ymm (256-bit) version since it would serve no purpose as it would produce the same result as the xmm one, and the corresponding intrinsics mostly follow the same pattern. So there is no int64 -> ymm intrinsic. An intrinsic cast works fine though: https://godbolt.org/z/M9XWCb https://godbolt.org/z/M9XWCb Intel even says about the cast: > Cast vector of type __m128i to type __m256i; the upper 128 bits of the result are undefined. This intrinsic is only used for compilation and does not generate any instructions, thus it has zero latency. That seems a bit beyond their mandate since what the compilers generate is mostly up to them, and in fact it doesn't seem true: at -O0, both gcc and clang generate a few extra instructions for the cast. With optimization on, it's all good though.

by nkurz 7y ago

BeeOnRope 7y ago

Yes, most instructions that modify only the bottom element(s) didn't get a ymm (256-bit) version since it would serve no purpose as it would produce the same result as the xmm one, and the corresponding intrinsics mostly follow the same pattern. So there is no int64 -> ymm intrinsic. An intrinsic cast works fine though: https://godbolt.org/z/M9XWCb https://godbolt.org/z/M9XWCb Intel even says about the cast: > Cast vector of type __m128i to type __m256i; the upper 128 bits of the result are undefined. This intrinsic is only used for compilation and does not generate any instructions, thus it has zero latency. That seems a bit beyond their mandate since what the compilers generate is mostly up to them, and in fact it doesn't seem true: at -O0, both gcc and clang generate a few extra instructions for the cast. With optimization on, it's all good though.