Qix*_*Qix 4 x86 sse simd intrinsics avx512
英特尔内在指南简单地指出_mm512_load_epi32:
从存储器加载[s] 512位(由16个打包的32位整数组成)到dst
那_mm512_load_si512:
将[s] 512位整数数据从内存加载到dst中
这两者有什么区别？文件不清楚.
Pet*_*des 11
没有区别,它只是愚蠢的冗余命名.使用_mm512_load_si512的清晰度. 谢谢,英特尔.像往常一样,它更容易理解AVX512底层ASM,然后你可以看到笨拙的内在命名想说.或者至少你可以理解我们如何最终得到这些混乱的不同文档建议_mm512_load_epi32与_mm512_load_si512.
几乎所有AVX512指令都支持合并屏蔽和零屏蔽.(例如,vmovdqa32可以执行掩码加载,就像零位vmovdqa32 zmm0{k1}{z}, [rdi]向量的零向量元素一样k1),这就是为什么存在诸如向量加载和按位运算之类的不同元素大小版本的原因.(例如vpxordvs.vpxorq).
但这些内在函数适用于无掩盖版本.元素大小完全无关紧要. 我猜测_mm512_load_epi32存在与_mm512_mask_load_epi32(merge-masking)和_mm512_maskz_load_epi32(zero-masking)的一致性.请参阅vmovdqa32asm指令的文档.
例如_mm512_maskz_loadu_epi64(0x55, x),在加载时将奇数元素免费归零.(至少它是免费的,如果把成本0x55变成一个k寄存器可以吊出一个循环.如果我们没有击败编译器的机会,折加载到内存操作的ALU指令).
当元素全部未加载到目标中时,元素边界毫无意义.这就是为什么AVX2和更早版本不具有不同的元素大小版本的按位布尔值_mm_xor_si128和加载/存储类似_mm_load_si128.
某些编译器不支持未对齐的未屏蔽加载的元素宽度名称.例如,当前gcc不_mm512_loadu_epi64支持,_mm512_load_epi64因为自第一个gcc版本支持AVX512内在函数以来它一直受支持.(见错误:'_mm512_loadu_epi64'未在此范围内声明)
没有CPU可以选择vmovdqa64与vmovdqa32效率相关的问题,因此无论数据的自然元素宽度如何,尝试提示编译器使用其中一个都是零点.
只有FP与整数对于负载才有意义,而英特尔的内在函数已经使用了不同的类型(__m512vs. __m512i).