IREE项目中GPU编译失败问题分析：分组卷积反向传播的两种实现方式

在IREE编译器项目中，开发人员遇到了一个关于GPU编译的有趣问题：两种逻辑上等效的分组卷积反向传播实现方式，在编译时表现出不同的行为。本文将深入分析这一现象的技术背景、问题本质以及解决方案。

问题背景

分组卷积(Grouped Convolution)是深度学习中的一种重要操作，它将输入和滤波器在通道维度上进行分组处理，能够显著减少计算量。在反向传播过程中，需要计算输入梯度，这涉及到特定的张量操作。

IREE项目中出现了两种实现分组卷积反向传播的中间表示(IR)：

1. 第一种实现：在卷积操作前后进行分组维度的展开和折叠，而在卷积内部先进行滤波器空间维度的翻转和梯度张量的填充。这种实现能够成功编译。

2. 第二种实现：在函数边界处进行展开/折叠操作，在展开后才应用滤波器翻转和填充。这种实现方式在编译时失败。

技术细节分析

编译失败原因

第二种实现方式编译失败的具体错误信息是共享内存使用超出限制(592944字节超过了65536字节的限制)。通过分析编译中间表示，可以发现问题出在内存使用优化上。

关键差异

两种实现的主要区别在于操作顺序：

• 成功实现：填充和翻转 → 展开 → 卷积 → 折叠
• 失败实现：展开 → 填充和翻转 → 卷积 → 折叠

失败实现中，由于先进行了张量展开，导致后续操作需要处理更高维度的张量，增加了内存需求。

深层原因

根本原因在于编译器优化阶段未能正确应用形状折叠优化。具体来说：

1. 失败实现中存在一个generic(collapse_shape(generic(...)))的操作链
2. 现有的FoldWithProducerReshapeOpByExpansion模式无法匹配这种情况
3. 虽然FoldReshapeWithGenericOpByCollapsing模式理论上可以解决这个问题，但它没有被包含在当前的优化流程中

解决方案

目前项目团队提出了几种解决思路：

1. 启用分组卷积的im2col路径：当分组卷积走im2col优化路径时，现有的模式能够正确处理这种情况。这是最根本的解决方案。

2. 临时修改控制函数：作为实验性方案，可以修改控制函数来允许应用FoldReshapeWithGenericOpByCollapsing模式。

3. 优化单次调度创建流程：在单次调度创建管道中添加适当的传递或模式来处理这种情况。

技术启示

这个问题揭示了深度学习编译器开发中的几个重要方面：

1. 操作顺序的重要性：看似逻辑等效的不同实现方式，在实际编译中可能产生截然不同的结果。

2. 优化模式覆盖：编译器需要覆盖各种可能的中间表示模式，特别是在处理复杂张量操作时。

3. 内存使用考量：GPU编程中内存使用是关键的优化点，编译器需要智能地管理内存需求。

随着IREE项目对分组卷积支持的不断完善，这类问题将得到系统性的解决。这也体现了编译器开发中需要不断优化和扩展模式匹配能力的必要性。