英特尔内在函数指南简单地说_mm512_load_epi32：
将 [s] 512 位（由 16 个压缩的 32 位整数组成）从内存加载到 dst
那_mm512_load_si512：
将 [s] 512 位整数数据从内存加载到 dst
这两者有什么区别？文档不清楚。
问问题
1248 次
1 回答
11
没有区别，只是愚蠢的冗余命名。为清楚起见使用_mm512_load_si512。 谢谢，英特尔。像往常一样，更容易理解 AVX512 的底层 asm，然后您可以看到笨拙的内在命名试图表达什么。或者至少你可以理解我们是如何最终得到这些乱七八糟的不同文档建议_mm512_load_epi32vs. _mm512_load_si512.
几乎所有 AVX512 指令都支持合并屏蔽和零屏蔽。（例如vmovdqa32，可以进行屏蔽加载，例如vmovdqa32 zmm0{k1}{z}, [rdi]将具有零位的向量元素k1归零），这就是为什么存在诸如向量加载和按位运算之类的不同元素大小版本的原因。（例如vpxord与vpxorq）。
但这些内在函数适用于无屏蔽版本。元素大小完全无关紧要。 我猜测_mm512_load_epi32存在与_mm512_mask_load_epi32（合并掩蔽）和_mm512_maskz_load_epi32（零掩蔽）的一致性。vmovdqa32有关asm 指令，请参阅文档。
例如_mm512_maskz_loadu_epi64(0x55, x)，加载时将奇数元素免费归零。（至少如果放入寄存器的成本可以从循环中提升出来，那么它是免费的0x55。k如果我们没有阻止编译器将负载折叠到 ALU 指令的内存操作数中的机会。）
当元素全部原封不动地加载到目的地时，元素边界是没有意义的。这就是为什么 AVX2 和更早版本没有不同的元素大小版本的按位布尔值_mm_xor_si128和像_mm_load_si128.
一些编译器不支持unaligned unmasked loading的元素宽度名称。例如，当前的 gcc 不支持_mm512_loadu_epi64，即使它_mm512_load_epi64从第一个支持 AVX512 内在函数的 gcc 版本开始就受到支持。（请参阅错误：'_mm512_loadu_epi64' 未在此范围内声明）
没有任何 CPU 的选择vmovdqa64与vmovdqa32效率无关紧要，因此无论数据的自然元素宽度如何，尝试提示编译器使用其中一个或另一个都是零点。
只有 FP 与整数可能对负载很重要，而英特尔的内在函数已经为此使用了不同的类型（__m512vs. __m512i）。
于 2018-12-23T18:55:40.063 回答