如何解决_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
加载等
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。