英特尔内部函数指南仅声明_mm512_load_epi32：
将512位（由16个压缩的32位整数组成）从内存加载到dst
和那个_mm512_load_si512：
将512位整数数据从内存加载到dst
两者之间有什么区别？文档不清楚。
答案 0 :(得分：10)
没有区别，只是愚蠢的冗余命名。为清楚起见，请使用_mm512_load_si512。谢谢，英特尔。像往常一样，更容易理解AVX512的底层asm，然后您可以看到笨拙的内在命名要表达的意思。至少，您至少可以了解我们是如何最终得到这些杂乱的文档的，这些文档建议_mm512_load_epi32与_mm512_load_si512。
几乎所有的AVX512指令都支持合并屏蔽和零屏蔽。
（例如vmovdqa32可以对vmovdqa32 zmm0{k1}{z}, [rdi]具有零位的零个向量元素进行类似k1的掩码加载，这就是为什么矢量加载和按位运算之类的元素大小版本不同的原因存在。 （例如vpxord vs. 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这样的装载/存储都没有不同的原因。
某些编译器不支持未对齐未屏蔽负载的元素宽度名称。例如自从第一个完全支持AVX512内在函数的gcc版本以来，当前gcc不支持_mm512_loadu_epi64，尽管它受支持_mm512_load_epi64。 （请参见error: '_mm512_loadu_epi64' was not declared in this scope）
在vmovdqa64和vmovdqa32的选择中，根本没有任何CPU对效率有影响，因此试图提示编译器使用一个或多个是没有意义的。另一个，不管数据的自然元素宽度如何。
只有FP与整数可能对负载很重要，并且Intel的内在函数已经为此使用了不同的类型（__m512与__m512i）。