OpenCL内核非确定性运行异常排查（Intel Gen9 GPU）

这个异常是稳定可复现的编译器路径缺陷，所有观测到的阈值特征完全匹配Intel Gen9 NEO驱动的已知bug模式：

• 异常触发的核心逻辑是私有数组的存储分配路径分支：当数组为double类型、编译期大小落在16元素到21元素区间（对应128B~168B）时，编译器会触发“寄存器溢出转本地内存”的中间优化路径，在这个路径上Gen9编译器存在动态索引地址计算错误：对于值恒为0的动态下标（也就是代码里的alpha_idx，因为num_fields=1，循环里计算出来的alpha_idx永远是0，但编译器无法做常量折叠传播），错误跳过了对应位置的累加写入操作，导致sum[0]一直保持初始的0值。
• 观测到的所有现象都和这个机制完全对应：
  • MAX_ORDER=1时数组仅占8B，完全存放在寄存器中，不走溢出优化路径，异常消失；
  • 1<MAX_ORDER<21时数组大小刚好落在bug触发的溢出处理区间，异常稳定复现；
  • MAX_ORDER≥22时数组大小超过176B，编译器会直接把私有数组映射到固定本地内存位置，绕过有bug的中间溢出路径，异常自动消失；
  • local_size降到8及以下时，单线程可分配的寄存器配额提升，同样大小的数组不需要触发寄存器溢出，也就不会走到有bug的代码分支，异常消失。

• 从OpenCL规范层面看，当前代码的私有内存使用是完全合法的：double sum[MAX_ORDER]是以编译期常量为长度的私有自动变量，初始化逻辑针对实际用到的下标范围（0到num_fields-1）做了零初始化，没有越界访问的问题。
• 这里存在一个容易被忽略的实际隐患：sum数组中从num_fields到MAX_ORDER-1的元素没有做零初始化，属于未初始化的野值。当前测试因为num_fields=1、实际只会访问sum[0]所以不会触发问题，但如果后续调整num_fields取值、或者循环逻辑出现超出已初始化范围的下标访问，就会触发未定义行为。
• 因为代码中存在通过变量alpha_idx的动态下标访问，编译器无法把sum数组完全优化成纯寄存器变量，必须为数组分配实际的存储单元——这个流程本身完全符合规范要求，不存在用户代码层面的违规。

当前异常属于明确的GPU编译器实现缺陷，不存在用户代码逻辑错误：

• 静态代码校验流程无法检出这类问题，是因为这类bug属于编译后目标码生成阶段的实现错误，不属于源码层面的语法违规、内存越界等可被静态扫描覆盖的问题。
• 临时绕开bug的两个低成本方案：
  • 直接把MAX_ORDER设置为22以上的固定值，避开有bug的优化区间；
  • 给sum数组加上volatile修饰，强制编译器跳过容易出问题的寄存器溢出优化，按稳定的内存访问逻辑生成目标码。
• 这类问题对应Intel Graphics Compute Runtime for Gen9平台的已知实现缺陷：在处理私有数组寄存器溢出的场景时，动态索引的偏移计算存在固定位宽截断错误，会跳过部分索引的内存访问操作。

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