ICC开启-O3优化时intrinsics异常，-O1/-O2或手动汇编可正常运行

这问题在AVX2 intrinsics优化场景里挺典型的，结合ICC的激进优化特性，我整理了几个最可能的原因，以及对应的验证方向：

1. 内存别名（Aliasing）引发的优化重排 #

ICC的-O3会启用非常激进的别名分析优化。如果编译器无法确定你的A、B、C三个指针指向的内存区域完全不重叠，它可能会重排内存读写的顺序——比如提前将未完成的计算结果写入C，后续的计算又错误地读取了这块被提前覆盖的内存，最终导致结果出错。

• _mm256_storeu_pd作为标准intrinsic，编译器会把它当作普通内存操作参与优化重排；而你手写的汇编store，编译器无法对其做任何优化，强制保证了代码的执行顺序。
• 验证方法：给函数参数加上__restrict__关键字，明确告诉编译器三个指针指向的内存互不重叠：

  inline void RunIntrinsics_FMA_UnalignedCopy_MultiplyMatrixByMatrix(
      double *__restrict__ A, 
      double *__restrict__ B, 
      double *__restrict__ C
  )
  

  如果加上后-O3下结果正常，那基本就是别名问题导致的。

2. ICC对_mm256_storeu_pd的-O3优化存在bug #

部分版本的ICC在-O3级别下，对_mm256_storeu_pd的代码生成可能存在问题：比如错误地将未对齐store的intrinsic编译成了对齐store指令（vmovapd），或者指令顺序生成错误。而手写汇编直接指定了正确的未对齐store指令（vmovupd），绕过了编译器的bug。

• 验证方法：用icc -S -O3生成汇编代码，对比_mm256_storeu_pd对应的指令，看是否是vmovupd（正确的未对齐store）；如果是vmovapd，那就是编译器的bug，需要升级ICC版本或者用汇编绕过。

3. 指令重排破坏了数据依赖 #

FMA矩阵乘法的计算存在严格的数据依赖：后续的计算步骤需要依赖前面步骤的结果。ICC的-O3可能过度优化，将_mm256_storeu_pd的写入操作提前，导致后续的计算错误地读取了还未完全计算完成的C内存值（如果存在别名的话）。

• 手写汇编的store相当于插入了一个隐式的内存屏障，阻止了编译器的指令重排，保证所有计算完成后再执行内存写入。
• 验证方法：在_mm256_storeu_pd之前插入一个内存屏障，比如：

  __asm__ __volatile__("":::"memory"); // 阻止编译器重排内存操作
  _mm256_storeu_pd(C + ..., ...);
  

  如果插入后结果正常，说明是指令重排导致的问题。

总结 #

最可能的原因是内存别名引发的优化重排，其次是ICC的intrinsic优化bug。建议先尝试添加__restrict__关键字，再通过查看汇编代码确认编译器的指令生成是否正确。

内容的提问来源于stack exchange，提问作者Denton