AVX512 - 如何将所有设置位向右移动？答案

【问题标题】：AVX512 - How to move all set bits to the right?AVX512 - 如何将所有设置位向右移动？
【发布时间】：2021-07-19 04:50:48
【问题描述】：

如何将掩码寄存器的所有设置位向右移动？（到底部，最不重要的位置）。

例如：

__mmask16 mask = _mm512_cmpeq_epi32_mask(vload, vlimit); // mask = 1101110111011101

如果我们将所有设置的位向右移动，我们将得到：1101110111011101 -> 0000111111111111

我怎样才能有效地做到这一点？

您可以在下面看到我如何尝试获得相同的结果，但效率低下：

__mmask16 mask = 56797;
// mask: 1101110111011101
__m512i vbrdcast = _mm512_maskz_broadcastd_epi32(mask, _mm_set1_epi32(~0));
// vbrdcast: -1 0 -1 -1 -1 0 -1 -1 -1 0 -1 -1 -1 0 -1 -1
__m512i vcompress = _mm512_maskz_compress_epi32(mask, vbrdcast);
// vcompress:-1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 0 0 0 0 
__mmask16 right_packed_mask =   _mm512_movepi32_mask(vcompress);   
// right_packed_mask: 0000111111111111

最好的方法是什么？

【问题讨论】：

您想要将结果作为矢量还是掩码？像这样的东西可以工作：(1 << __builtin_popcount(_cvtmask16_u32(mask))) - 1（计算设置了多少位，然后创建一个掩码）
我想要结果作为掩码。 mask = ( 1 << bit_count ( .. ) ) -1 工作正常。谢谢！我想知道是否有另一种方法可以在没有标量代码的情况下做到这一点。
其实你的方案比我的效率高

标签： c bit-manipulation simd intrinsics avx512

【解决方案1】：

BMI2 pext 是 v[p]compressd/q/ps/pd 的标量按位等价物。
在您的掩码值上使用它以将它们左打包到值的底部。

  mask = _pext_u32(-1U, mask);    // or _pext_u64(-1ULL, mask64)  for __mmask64
// costs 3 asm instructions (kmov + pext + kmov) if you need to use the result as a mask
// not including putting -1 in a register.

__mmask16（在 GCC 中也称为 uint16_t）和 uint32_t 之间的隐式转换有效。
如果您愿意，可以使用 _cvtu32_mask16 和 _cvtu32_mask16 使 KMOVW 显式化。

有关以此类方式使用 pext/pdep 的更多信息，请参阅How to unset N right-most set bits。

当前所有配备 AVX-512 的 CPU 也具有快速的 BMI2 pext（包括 Xeon Phi），与 popcnt 的性能相同。在 Zen 3 之前，AMD 的 pext 很慢，但是如果/当 AMD 推出 AVX-512 CPU 时，它应该有很快的 pext/pdep。

对于没有 AVX512 的早期 AMD，您可能需要(1ULL << __builtin_popcount(mask)) - 1，但如果所有位都已设置，请注意溢出。 1ULL << 64 是未定义的行为，在为 x86-64 编译时可能会产生 1 而不是 0。

如果您打算使用vpcompressd，请注意源向量可以简单地为全一_mm512_set1_epi32(-1)； compress 不关心掩码为零的元素，它们不需要已经为零。

（您打包-1s 并不重要哪个；一旦您使用布尔值，来自原始位掩码的true 与来自原始位掩码的true 没有区别常量true 只是坐在那里，您可以更便宜地生成它，而不依赖于您的输入掩码。同样的推理适用于pext，为什么您可以使用-1U 作为源数据而不是pdep。即-1 或设置位没有标识；它与任何其他 -1 或设置位相同。

所以让我们尝试两种方法，看看 asm 的优劣。

inline
__mmask16 leftpack_k(__mmask16 mask){
    return _pdep_u32(-1U, mask);
}

inline
__mmask16 leftpack_comp(__mmask16 mask) {
    __m512i v = _mm512_maskz_compress_epi32(mask, _mm512_set1_epi32(-1));
    return _mm512_movepi32_mask(v);
}

查看这些的独立版本没有用，因为__mmask16 是unsigned short 的类型定义，因此在整数寄存器中传递/返回，而不是在k 寄存器中。当然，这使得pext 版本看起来非常好，但我们想看看它如何内联到我们生成和使用带有 AVX-512 内在函数的掩码的情况。

// not a useful function, just something that compiles to asm in an obvious way
void use_leftpack_compress(void *dst, __m512i v){
    __mmask16 m = _mm512_test_epi32_mask(v,v);
    m = leftpack_comp(m);
    _mm512_mask_storeu_epi32(dst, m, v);
}

注释掉m = pack(m)，这只是一个简单的2条指令，生成然后使用掩码。

use_mask_nocompress(void*, long long __vector(8)):
        vptestmd        k1, zmm0, zmm0
        vmovdqu32       ZMMWORD PTR [rdi]{k1}, zmm0
        ret

所以任何额外的指令都是由于左包装（压缩）掩码。 GCC 和 clang 彼此组成相同的 asm，不同之处仅在于 clang 避免 kmovw 而始终支持 kmovd。 Godbolt

# GCC10.3 -O3 -march=skylake-avx512
use_leftpack_k(void*, long long __vector(8)):
        vptestmd        k0, zmm0, zmm0
        mov     eax, -1                        # could be hoisted out of a loop
        kmovd   edx, k0
        pdep    eax, eax, edx
        kmovw   k1, eax
        vmovdqu32       ZMMWORD PTR [rdi]{k1}, zmm0
        ret

use_leftpack_compress(void*, long long __vector(8)):
        vptestmd        k1, zmm0, zmm0
        vpternlogd      zmm2, zmm2, zmm2, 0xFF   # set1(-1)  could be hoisted out of a loop
        vpcompressd     zmm1{k1}{z}, zmm2
        vpmovd2m        k1, zmm1
        vmovdqu32       ZMMWORD PTR [rdi]{k1}, zmm0
        ret

所以不可提升的部分是

kmov r,k (port 0) / pext (port 1) / kmov k,r (port 5) = 3 uop，每个执行端口一个。（包括端口 1，它的矢量 ALU 在 512 位微指令运行时关闭）。 kmov/kmov 往返有4 cycle latency on SKX，pext 是 3 个周期延迟，总共有 7 个周期延迟。
vpcompressd zmm{k}{z}, z (2 p5) / vpmovd2m (port 0) = 3 uops，两个用于端口 5。vpmovd2m 有 3 cycle latency on SKX / ICL，vpcompressd-zeroing-into-zmm 有 6 个周期从 k 输入到 zmm 输出（SKX 和 ICL）。所以总共有 9 个周期延迟，并且 uop 的端口分布更差。

此外，可提升部分通常更差（vpternlogd 比 mov r32, imm32 更长并且竞争的端口更少），除非您的函数已经需要一个全为向量而不是全一寄存器。

结论：BMI2pext方式在任何方面都不差，在几个方面更好。（除非周围的代码严重在端口 1 微指令上出现瓶颈，如果使用 512 位向量，这不太可能，因为在这种情况下，它只能运行标量整数微指令，如 3 周期 LEA、IMUL、LZCNT、当然还有简单的 1 周期整数，比如 add/sub/and/or)。

【讨论】：

感谢您的总结——非常有帮助！