_mm256_loadu_epi64、_mm256_storeu_epi64 需要 avx512vl？ 我认为我应该为我的 avx2 机器编译：编译但让我紧张：似乎有效：问题

问题描述

第一次使用 avx2 内在函数（在支持 avx2 但不 avx512 的系统上）。

无论是从原型还是我从英特尔内在函数参考中获得的信息，我都会假设 _mm256_loadu_epi64 和 _mm256_storeu_epi64 是 avx512 函数。

但是如果我只用 -mavx2 编译代码，我会得到编译器错误。另一方面，如果我用 -mavx512vl 编译（按照编译器错误的建议），它会编译并且似乎可以工作。但是，如果我选择 avx512，我当然会担心编译器在程序的其余部分可能会做什么......

我认为我应该为我的 avx2 机器编译：

clang++ -std=c++17 -O2 -mavx2 -o storeload dummy.cpp
dummy.cpp:16:21: 错误：always_inline 函数
“_mm256_loadu_epi64”需要目标功能“avx512vl”，
但会被内联到函数“main”中，即
编译时不支持“avx512vl”
__m256i avx2reg = _mm256_loadu_epi64(&input[0]);
^
dummy.cpp:17:3: 错误：always_inline 函数
“_mm256_storeu_epi64”需要目标特征“avx512vl”，
但会被内联到函数“main”中，即
编译时不支持“avx512vl”
_mm256_storeu_epi64(&output[0],avx2reg);
^
产生了 2 个错误。

编译但让我紧张：

clang++ -std=c++17 -O2 -mavx512vl -o storeload dummy.cpp

似乎有效：

./storeload
0x1111111111111111 == 0x1111111111111111 ?
0x2222222222222222 == 0x2222222222222222 ?
0x3333333333333333 == 0x3333333333333333 ?
0x4444444444444444 == 0x4444444444444444？

编译器是

clang --version
Debian clang 版本 11.0.1-2
目标：x86_64-pc-linux-gnu
线程模型：posix
安装目录：/usr/bin

测试代码是

#include <cstdint>
#include <array>
#include <cinttypes>
#include <iostream>
#include <immintrin.h>

int main(int argc,const char* argv[]) {
  std::array<uint64_t,4> input
    { UINT64_C(0x1111111111111111),UINT64_C(0x2222222222222222),UINT64_C(0x3333333333333333),UINT64_C(0x4444444444444444) };
  std::array<uint64_t,4> output;
  output.fill(UINT64_C(0));

  __m256i avx2reg = _mm256_loadu_epi64(&input[0]);
  _mm256_storeu_epi64(&output[0],avx2reg);

  std::cout << std::hex << std::showbase;
  
  for (size_t i=0; i < input.size(); i++) {
    std::cout << input[i] << " == " << output[i] << " ?" << std::endl;
  }
  
  return 0;
}

问题

• 这是一个编译器错误，在只有 avx2 应该做的时候要求 avx512？
• 当我启用 avx512 时，如何确保代码（还有更多代码，未在这个最小示例中显示）不会在我的 avx2 系统上崩溃？
• 是否有我可以/应该使用的替代功能？
• 是否有我应该使用但尚未找到的替代 -m 标志？

解决方法

使用 _mm256_loadu_si256((const __m256i*) ptr) 和 _mm256_storeu_si256，另见 How to emulate _mm256_loadu_epi32 with gcc or clang?

---

那些具有更好 arg 类型（void* 而不是 __m256i*）的内在函数是与其他 AVX-512 内在函数一起引入的，但是执行 256 位加载的最有效方法是使用 AVX1 {{1 }} 或 vmovdqu（或任何指令的内存源操作数）。这就是为什么 clang 最终生成可以在您的 CPU 上运行的代码。 （使用反汇编器或 vmovups 检查 asm 输出）

不幸的是，clang 甚至不允许您在未启用 AVX-512VL 的情况下使用 clang -march=native -O3 foo.cpp -S -o - | less 版本，因为它们不执行任何只能使用 AVX-512 实现的操作；只有像 void* 这样的 intrinsics for vmovdqu64 的掩码版本才真正有意义，其中 _mm256_mask_storeu_epi64 元素的大小具有任何意义（掩码粒度）。

如果您的 CPU 不支持，那么使用 epi64 是不安全的。 （Skylake-X、冰湖等）。 clang 本可以决定实际使用它，例如使用 ymm15..31 来避免 vzeroupper，或将一对按位布尔内在函数编译为 -mavx512vl，或将 vpternlogd 折叠到广播内存源操作数中以用于 _mm256_set1_epi32 (vpaddd ).

或者作为一个错过的优化（更大的代码大小），实际上使用 _mm256_add_epi32 而不是 vmovdqu64 来加载存储 ymm0..15。 GCC 已经/有这个错误有一段时间了。

为什么我使用的函数是前缀 _mm256 而不是 _mm512？

AVX-512VL（VL=Vector Length）的全部意义在于 128 位和 256 位版本的 AVX-512 引入的很酷的新东西，比如屏蔽存储和屏蔽寄存器写入、两倍多的向量寄存器、广播内存源操作数而不是需要单独的 vmovdqu 加载等