在保持 YMM 部分不变的情况下，对 XMM 寄存器执行 PSRLDQ 的正确内在顺序是什么？

Question

假设xmm0是第一个参数，这就是我想要生成的那种代码。

psrldq xmm0, 1
vpermq ymm0, ymm0, 4eh
ret

我用内在函数写了这个。

__m256i f_alias(__m256i p) {
    *(__m128i *)&p = _mm_bsrli_si128(*(__m128i *)&p, 1);
    return _mm256_permute4x64_epi64(p, 0x4e);
}

这是clang的结果，没关系。

f_alias: #clang
        vpsrldq xmm1, xmm0, 1
        vperm2i128      ymm0, ymm0, ymm1, 33
        ret

但是gcc会产生错误的代码。

f_alias: #gcc
        push    rbp
        vpsrldq xmm2, xmm0, 1
        mov     rbp, rsp
        and     rsp, -32
        vmovdqa YMMWORD PTR [rsp-32], ymm0
        vmovdqa XMMWORD PTR [rsp-32], xmm2
        vpermq  ymm0, YMMWORD PTR [rsp-32], 78
        leave
        ret

我尝试了不同的版本。

__m256i f_insert(__m256i p) {
    __m128i xp = _mm256_castsi256_si128(p);
    xp = _mm_bsrli_si128(xp, 1);
    p = _mm256_inserti128_si256(p, xp, 0);
    return _mm256_permute4x64_epi64(p, 0x4e);
}

clang产生相同的代码。

f_insert: #clang
        vpsrldq xmm1, xmm0, 1
        vperm2i128      ymm0, ymm0, ymm1, 33
        ret

但是gcc在翻译内在函数时过于直白。

f_insert: #gcc
        vpsrldq xmm1, xmm0, 1
        vinserti128     ymm0, ymm0, xmm1, 0x0
        vpermq  ymm0, ymm0, 78
        ret

用内在函数编写此操作的好方法是什么？ 如果可能的话，我想让gcc产生像clang这样的好代码。

一些附带问题。

1. 将PSRLDQ与 AVX 代码混合使用是不是很糟糕？ 像clang那样使用VPSRLDQ会更好吗？ 如果使用PSRLDQ没有任何问题，这似乎是一种更简单的方法，因为它不像VEX版本那样将YMM部分归零。
2. 同时拥有VINSERTI128 / VPERMI128和VINSERTF128 / VPERMF128的目的是什么？

Answer 1

我犯傻了。 clang给了我答案，我怎么没注意到呢？

vpsrldq xmm1, xmm0, 1
vperm2i128      ymm0, ymm0, ymm1, 33
ret

这个序列很简单，

__m256i f_____(__m256i p) {
    __m128i xp = _mm256_castsi256_si128(p);
    xp = _mm_bsrli_si128(xp, 1);
    __m256i _p = _mm256_castsi128_si256(xp);
    return _mm256_permute2x128_si256(p, _p, 0x21);
}

事实上gcc也产生高效的代码..

f_____:
        vpsrldq xmm1, xmm0, 1
        vperm2i128      ymm0, ymm0, ymm1, 33
        ret

Answer 2

Skylake 上的最佳 asm 将使用旧版 SSE psrldq xmm0, 1 ，其效果是保持向量的 rest 不变，作为数据依赖项处理。 （在寄存器上，指令无论如何都会读取，因为这不是movdqa或其他东西）。 但这在 Haswell 或 Ice Lake 上将是灾难性的，当任何 YMM 具有“脏”上半部分时，旧版 SSE 指令写入 XMM 寄存器时，两者都需要代价高昂地过渡到“已保存的鞋面”state。 我不确定 Zen1 或 Zen2/3/4... 如何处理它。

在 Skylake 上几乎一样好，并且在其他任何地方都最佳，是先复制和移位，然后vpblendd复制到原始的高半部分，因为您不需要在 128 位通道之间移动任何数据。 vpblendd比任何 shuffle 更高效，能够在多个执行端口中的任何一个上运行，在 Intel CPU 上具有 1 个周期延迟。 （像vperm2i128这样的通道交叉洗牌在主流 Intel 上是 1 uop / 3 周期延迟，在 AMD 和 Alder Lake 的 E 核心上明显更差。https://uops.info/ ）相比之下，变量与矢量控制通常更昂贵，但即时混合非常好。

是的，在某些 CPU 上使用 XMM ( __m128i ) 移位会更有效，而不是移动两半然后与原件混合。 这将减少使用强制转换内在函数的输入，但如果编译器没有对其进行优化，那么您将在 Zen1 和 Alder Lake E-cores 上浪费微指令，其中vpsrldq ymm的每一半都需要一个单独的微指令。

__m256i rshift_lowhalf_by_1(__m256i v)
{
    __m128i low = _mm256_castsi256_si128(v);
   low = _mm_bsrli_si128(low, 1);
   return _mm256_blend_epi32(v, _mm256_castsi128_si256(low), 0x0F);
}

gcc/clang 使用 xmm byte-shift 和 YMM vpblendd将其编译为书面（ Godbolt ）。 （Clang 翻转立即数并使用相反的源寄存器，但相同的区别。）

vpblendd在 Zen1 上是 2 uops，因为它必须处理向量的两半。 对于特殊情况，例如保留整个向量的一半，解码器不会立即查看。 它仍然可以复制到单独的目标，而不必就地覆盖任一源。 出于类似的原因，不幸的是， vinserti128也是 2 微指令。 （ vextracti128在 Zen1 上只有 1 uop；我希望vinserti128将只有 1，并在检查 uops.info 之前编写了以下版本）：

// don't use on any CPU *except* Zen1, or an Alder Lake pinned to an E-core.
__m256i rshift_alder_lake_e(__m256i v)
{
    __m128i low = _mm256_castsi256_si128(v);
   low = _mm_bsrli_si128(low, 1);
   return _mm256_inserti128_si256(v, low, 0);  // still 2 uops on Zen1 or Alder Lake, same as vpblendd
    // clang optimizes this to vpblendd even with -march=znver1.  That's good for most uarches, break-even for Zen1, so that's fine.
}

Alder Lake E-cores 可能有一个小的好处，其中vinserti128延迟被列为[1;2]而不是vpblendd的平坦2 。 但是由于任何 Alder Lake 系统也将具有 P 内核，因此您实际上并不希望使用vinserti128 ，因为它在其他所有方面都更糟糕。