是否有 AVX2 指令和内在指令可以将 16 位值广播 16 次加载到 __m256i 中？

编程问答 2022-04-23

问题描述

在下面的代码中，我可以使用avx2来计算每个位置1位的数量 一次单独 16 位，但在标记为 loadLow16 的行上缺少 4 条指令。我需要一条指令来加载 16 位值并将其放入 avx2 寄存器的每 16 位（16 次）。是否有执行此操作的说明，或者是否有更好的方法来执行此操作？

void countHistBits4(const uint64_t p[],uint32_t n,uint32_t hist[64]) {
  uint16_t masks[16] = {1,1<<1,1<<2,1<<3,1<<4,1<<5,1<<6,1<<7,1<<8,1<<9,1<<10,1<<11,1<<12,1<<13,1<<14,1<<16};
    __m256i mask = _mm256_load_si256((__m256*)masks);
    __m256i count1 = _mm256_setzero_si256();
    __m256i count2 = _mm256_setzero_si256();
    __m256i count3 = _mm256_setzero_si256();
    __m256i count4 = _mm256_setzero_si256();
    for (uint32_t i = 0; i < n; i++) {
      __m256i v1 = loadLow16(p[i] & 0xFFFF);
      __m256i v2 = loadLow16((p[i] >> 16) & 0xFFFF);
      __m256i v3 = loadLow16((p[i] >> 32) & 0xFFFF);
      __m256i v4 = loadLow16((p[i] >> 48) & 0xFFFF);
      v1 = _mm256_and_si256(v1,mask);
      count1 = _mm256_adds_epi16 (count1,vals);
      v2 = _mm256_and_si256(v2,mask);
      count2 = _mm256_adds_epi16 (count2,vals);
      v3 = _mm256_and_si256(v3,mask);
      count3 = _mm256_adds_epi16 (count3,vals);
      v4 = _mm256_and_si256(v4,mask);
      count4 = _mm256_adds_epi16 (count4,vals);
    }
}

解决方法

对于您的整体位置流行计数问题，请参阅 https://github.com/mklarqvist/positional-popcount 以获得高度优化的实现，这也是正确的，与此不同，您显然还没有时间调试，因为您缺少构建块。在 x & (1<<15) 元素中添加多个 int16_t 结果会立即饱和，因此您需要一些东西，可能是可变计数移位或像 x & mask == mask 这样的比较。或者可能更好地重新设计：相关的 SO Q&A：

标题问题：广播一个uint16_t

指令是vpbroadcastw。它适用于内存或 xmm 源。在 Intel CPU 上，它解码为加载和随机播放（端口 5）微指令，与纯粹在加载端口处理的 32、64 或 128 位广播不同。

它的内在函数是：

  • __m256i _mm256_set1_epi16( int16_t ) - 如果您只有一个标量。
  • __m256i _mm256_broadcastw_epi16 (__m128i a) - 广播向量的底部元素。

为了避免违反 C 中的严格别名规则，您正确地认为访问 uint64_t p[] 元素并屏蔽它们是一种安全的方法，而指向它的 uint16_t * 则不然。 （如果您正常取消引用它；但不幸的是，没有负载内在函数将取消引用隐藏在别名安全的内在函数中，因此您必须将 memcpy 放入 uint16_t tmp var 或其他内容...）

现代 GCC 足够聪明，可以将 __m256i v4 = _mm256_set1_epi16((p[i] >> 48) & 0xFFFF); 编译成 vpbroadcastw ymm0,WORD PTR [rdi+6+rdx*8]，而不是像实际的 64 位标量移位然后 vmovd + xmm-source 广播那样做任何愚蠢的事情。 （即使只有 -Og https://godbolt.org/z/W6o5hKTbz）

但那是只使用其中一个计数，其他优化掉的情况。 （我只是使用了 volatile __m256i sink 来分配事物，以此来阻止优化器完全删除循环。）

https://godbolt.org/z/fzs9PEbMq 展示了更重的优化，使用 count2 和 count4 使 GCC 对 uint64_t 进行标量加载，并在 vmovd xmm0,edx / ... / {{ 1}}。所以这很糟糕。 ：/

vmovd xmm0,eax

为了确保安全，您可以将 // compiles to a vpbroadcastw load with an offset // but violates strict aliasing __m256i v2 = _mm256_set1_epi16( *(1 + (uint16_t*)&p[i]) ); 用于临时或 GNU C memcpy。 （__attribute__((may_alias)) 本身的定义中使用了相同的属性）。

__m256i

编译 4 次 vpbroadcastw 加载 (https://godbolt.org/z/6v9esqK9P)。 （省略了使用这些负载的说明）

typedef uint16_t aliasing_u16 __attribute__((aligned(1),may_alias));

      __m256i v1 = _mm256_set1_epi16(*(0 + (aliasing_u16*)&p[i]));
      __m256i v2 = _mm256_set1_epi16(*(1 + (aliasing_u16*)&p[i]));
      __m256i v3 = _mm256_set1_epi16(*(2 + (aliasing_u16*)&p[i]));
      __m256i v4 = _mm256_set1_epi16(*(3 + (aliasing_u16*)&p[i]));

这可能更好地避免 Intel CPU 上端口 5 的瓶颈。 vpbroadcastw ymm1,WORD PTR [rdi] ... add rdi,8 vpbroadcastw ymm1,WORD PTR [rdi-6] ... vpbroadcastw ymm1,WORD PTR [rdi-4] ... vpbroadcastw ymm1,WORD PTR [rdi-2] ... 和 vmovd xmm,eax 都是 1 uop，只能在 Skylake 系列 CPU 的端口 5 上运行。 (https://agner.org/optimize/ https://uops.info/)。

带有内存源的

vpbroadcastw ymm,xmm 仍然需要 shuffle uop (p5)，但是从其他地方获取数据到 SIMD 域使用加载端口而不是另一个端口 5 uop。并且它可以将负载微融合到单个前端 uop 中。

avxavx2c++intrinsicssse