动手实践：实现融合遍

优化遍将效率低的计算图转换成能在目标硬件上快速执行的形式。算子融合的性能优势已广为人知，但其实际实现需要直接操作底层的中间表示 (IR) 数据结构。我们现在将构建一个编译器遍，用于识别特定模式，即逐元素加法后跟一个修正线性单元 (ReLU)，并将它们融合为一个操作。

此过程依赖于三个工程支柱：图遍历、模式匹配和图重写。

融合候选对象

考虑ResNet架构中常见的一个子图：偏置加法或残差连接紧接着一个激活函数。在朴素的执行引擎中，此序列会触发两个独立的核函数。

$Y = A + B$ $Z = \text{max}(0, Y)$

中间张量 $Y$ 由加法器写入主内存 (DRAM)，并立即由激活函数读回。这种往返操作会消耗宝贵的内存带宽。通过将这些融合为一个通用 AddRelu 算子，中间结果会留在寄存器文件或L1缓存中。

图的初始状态如下所示：

数据依赖关系的图示，其中加法操作产生一个中间张量，该张量仅由ReLU操作使用。

实现访问者模式

编译器基础设施，如TVM和MLIR，使用访问者模式来遍历和修改IR。“修改器”类会遍历抽象语法树 (AST) 或有向无环图 (DAG)。当它遇到一个节点时，它可以返回一个新的、已修改的节点，或者原始节点。

为了实现融合，我们定义一个 FusionMutator，它会寻找 ReLU 算子。在递归的后序遍历中，我们首先访问输入（子节点）。当访问器返回到 ReLU 节点时，它会检查其生产者的性质。

以下是这种遍的结构逻辑，使用高级编译器原型开发中常见的类似Python的语法：

class FusionMutator(ExprMutator):
    def visit_call(self, call_node):
        # 首先，访问参数以确保自底向上的处理
        new_args = [self.visit(arg) for arg in call_node.args]

        # 检查当前节点是否为ReLU操作
        if call_node.op.name == 'nn.relu':
            # 检查ReLU的输入（生产者）
            producer = new_args[0]

            # 模式匹配：生产者是“加法”操作吗？
            if isinstance(producer, Call) and producer.op.name == 'add':
                return self.fuse_ops(producer, call_node)

        # 如果不匹配，返回带有潜在更新参数的节点
        return Call(call_node.op, new_args)

    def fuse_ops(self, add_node, relu_node):
        # 创建一个新的复合算子
        fused_op = Op.get('fused.add_relu')

        # 新算子接收“加法”节点的输入
        # 有效地绕过原始的中间结果
        return Call(fused_op, add_node.args)

安全检查和多消费者分析

上述代码描述了基本机制，但生产级别的编译器需要周密的安全检查。如果 add 操作的中间结果被图中的其他节点使用，朴素的融合是危险的。

如果 add 节点有多个消费者，将其融合到 ReLU 中会隔离逻辑。其他消费者将失去其输入来源，或者编译器需要复制 add 计算，这可能降低性能。

在重写之前，我们必须查询使用-定义链。融合仅在以下情况才有效：

1. add 节点支配 ReLU 节点。
2. ReLU 节点是 add 节点输出的唯一消费者。

我们可以通过支配分析遍或通过维护图节点的引用计数来验证这种拓扑结构。

def is_valid_fusion_candidate(producer, consumer, dependency_graph):
    # 检查1：架构特定限制
    # 例如，确保融合核函数支持数据类型
    if producer.dtype != 'float32':
        return False

    # 检查2：多消费者检查
    # 如果生产者的输出流向当前消费者以外的节点，
    # 我们就不能在不复制的情况下进行融合。
    users = dependency_graph.get_users(producer)
    if len(users) > 1:
        return False

    return True

重写阶段

一旦模式匹配并通过安全检查，修改器执行图替换。原始的 add 和 relu 节点被断开，并插入一个新的 fused.add_relu 节点。这个新节点继承了原始 add 节点的输入边，并连接到原始 relu 节点的输出边。

生成的IR更紧凑。后端代码生成器 (Codegen) 会将这个单节点映射到一个专门的核函数实现，也许是一个单一的CUDA核函数启动，或是一个利用向量累加寄存器的特定LLVM指令序列。

融合遍后的转换图。两个核函数已合并为一个，消除了中间内存事务。

对转换进行基准测试

为验证此遍的有效性，我们比较执行时间和内存流量。在涉及大张量（例如 $1024 \times 1024$）的典型场景中，融合核函数表现出更低的延迟，主要由于全局内存访问的减少。

下图表示在标准GPU加速器上，未融合和已融合实现之间的性能对比。

性能分析数据显示内存流量和延迟的减少。注意内存操作减少了一半，因为中间的写入-读取循环被消除。

在XLA或TVM等高级编译器中，这种逻辑超越了简单的二元操作。同样的原理也适用于将卷积与偏置加法、缩放因子和激活函数 (Conv-Bias-Scale-ReLU) 进行融合，这通常为推理工作负载带来2到3倍的加速。您现在已经实现了检测和优化这些模式所需的核心逻辑。