Slang编译器CUDA代码生成问题分析与修复

问题背景

在Slang编译器项目中，开发团队发现当使用新的编译API时，生成的CUDA中间代码存在语法错误。具体表现为在处理计算着色器的线程ID访问时，生成了无效的指针解引用操作。

问题现象

当编译一个简单的计算着色器时，新API生成的CUDA代码包含如下错误语句：

uint _S2 = (&_S1).x;

这段代码尝试对uint3类型的指针直接进行成员访问，这在CUDA/NVRTC中是不合法的语法。正确的做法应该是先解引用指针，再进行成员访问。

根本原因分析

通过深入调查，团队发现问题的根源在于新旧API对入口函数参数的处理方式不同：

1. 旧API生成的IR函数签名为：

Func(Void, ConstRef(Vec(UInt, 3 : Int)))

参数被标记为常量引用(ConstRef)，这使得后续优化能够正确处理参数访问。

2. 新API生成的IR函数签名为：

Func(Void, Vec(UInt, 3 : Int))

参数没有被标记为引用，导致在后续处理中产生了错误的指针操作。

进一步追踪发现，这种差异源于编译器前端对入口函数属性的处理不一致。旧API会自动为入口函数添加EntryPointAttribute装饰，而新API在某些情况下（如缺少显式着色器属性时）会遗漏这一关键信息。

解决方案

团队采取了以下修复措施：

1. 完善入口函数识别逻辑：不仅检查EntryPointAttribute，还考虑其他指示入口函数的特征（如计算着色器的numthreads属性）。

2. 确保一致的参数处理：无论通过哪种API路径，都保证入口函数参数被正确标记为常量引用。

3. 优化代码生成流程：在IR转换阶段增加对参数访问模式的校验，防止生成无效的指针操作。

技术影响

这一修复不仅解决了直接的代码生成问题，还带来了以下技术收益：

1. API一致性：确保新旧编译API在核心功能上表现一致。

2. 代码健壮性：增强了对各种着色器声明形式的支持。

3. 未来兼容性：为后续的编译器优化提供了更可靠的中间表示。

经验总结

这个案例展示了编译器开发中的几个重要经验：

1. API设计影响深远：即使是内部API的变化，也可能导致意想不到的语义差异。

2. 属性系统的重要性：编译器属性不仅影响代码生成，还可能改变优化路径。

3. 测试覆盖的必要性：需要针对不同API路径和着色器声明形式进行全面测试。

通过这次问题修复，Slang编译器在CUDA代码生成方面的稳定性和可靠性得到了进一步提升。