Pass管理：死代码消除DCE

可视化演示

展示DCE的活性分析核心机制：从输出反向传播活跃集合，识别并删除无副作用、结果未被使用的死代码，缩小IR体积。

核心目标：扔掉永远不会用到的“破外套”

阿安打开源码里生成的中间表示（IR），仿佛打开一个塞满东西的行李箱。里面有一堆“看起来很努力”的计算操作：有的算乘法，有的算 tanh，有的算 log。但 Leader 告诉他：“里面有些东西，算了也白算——因为它的结果根本不会影响模型的最终输出。”

这些“算了也白算”的操作，就是 死代码。DCE（Dead Code Elimination）的目标，就是把它们从行李箱里挑出来扔掉。判断标准有两条：第一，这个操作 没有副作用——它不打印、不写内存、不改变任何外部可见的状态，就像一件躺在箱底的旧外套不碰不响；第二，它的 结果没有任何人使用——没有后续操作消费它的输出，就像这件外套永远不会再被穿上。两个条件同时满足，编译器才能安全删除它。

安全，是 DCE 的底线。传统的“手动删代码”靠人的直觉，而 DCE 靠严格的证明：只有证明了某个操作既不起作用、又没副作用，才会动手。这样一来，IR 的体积减小了、后端代码生成的负担减轻了，而程序的语义（模型最终算出的结果）分毫不变。

阿安恍然大悟：“原来扔掉一件东西，不是因为'我觉得没用'，而是因为它确实不被需要，也碰不到任何其他东西。”

依赖分析基础：弄清行李箱里的“连带关系”

光知道“没人用的东西该扔”还不够。阿安很快发现，有些物品之间藏着连带关系：帐篷和帐篷支架是一对，带上帐篷就必须带支架；露营灯依赖电池，没电池灯就是废铁。行李箱里的每件物品，都被一张看不见的“依赖网”拴着。

编译器里这张网叫 def-use 链。一个 op 会 “def“（定义）一个值，其他操作则 ”use“（使用）这个值作为输入。DCE 要做的事，就是顺着这张网反向摸清”谁依赖谁”。举例来说，如果操作 C 使用操作 A 的输出作为输入，那么当 C 被保留时，A 通常也得保留——因为 C 的运行少不了 A 喂过来的数据。

同时还要警惕一类特殊物品：有副作用的操作。它们就像辣椒水喷雾——虽然平时没人“用它”（结果无人消费），但只要它存在，就可能在某个时刻对外界喷一下（打印、写内存、触发随机事件）。这类操作即使在依赖网里“没有下家”，DCE 也无权扔掉它，因为删掉它可能会改变程序对外部世界的可见行为。

基于这张网，编译器给每个值定义一个 活跃性：一个值只要还有任何一个“被标记保留”的操作在消费它，它就是活跃的（活的）；反过来，若它的所有潜在消费者都死了，它就跟着死掉。

阿安在笔记本上画下这张依赖网，感叹道：“原来判断一件行李该不该留，得先问清楚：还有谁在用它？”

工作流程：三步打包法

有了依赖分析这张“物品关系图”，阿安总结出了 DCE 的 三步打包法。这是整个优化最核心的操作流程。

第一步，收集根集合。根是“无论如何都必须保留”的操作，包括两类：一是带有副作用的操作（如打印、写内存），二是输出被外部世界消费的操作（如函数的返回结果）。它们就像旅行前确定的“必带清单”——清单上的东西一样都不能少。

第二步，反向标记传播。从根集合出发，沿着 def-use 链的反方向（从消费者回溯到生产者）逐步扩散：凡是被标记操作依赖的生产者，一律打上“保留”的标记。这个过程就像从必带清单倒推——既然要带帐篷，那帐篷支架和地钉也得进清单。

第三步，删除未标记操作。遍历完整张图后，把所有没有被标记的操作收集起来，统一从 IR 中抹去。由于所有有副作用的操作一开始就在根集合里，所以能走到这一步的操作，必然是无副作用的“纯计算”，删除它们绝对安全无事故。

阿安把三步打包法写在了工位上——“先定必带清单，再反推依赖，剩下的全扔掉”。这个流程清晰、安全、可证明。

MLIR实现机制：打包App的运行原理

阿安开始读 MLIR 的源码，想看看 DCE 在真实系统里长什么样。他发现，在 MLIR 的世界里，DCE 被封装成了一个 标准 Pass。所谓 Pass，就是一个独立可复用的优化模块，有点像手机里的“打包 App”——用户（编译器工程师）不需要自己动手翻行李箱，只要按下按钮，App 就会自动执行整理流程。

要让 App 能被调用，第一步是 注册 Pass。MLIR 有一套 Pass 注册机制，开发者可以在任意位置声明并注册一个新的 DCE Pass，随后它就能被插入到优化流水线中，和其他 Pass 按顺序执行。这就像在手机应用商店上架一个新的“打包工具”，装好后随时可以启动。

真正干活时，Pass 内部要回答一个问题：“这个操作的结果到底有没有消费者？” 对应的工具是 use_empty() 查询——它直接检查某个操作的结果是否没有任何使用记录。如果返回真，说明这个操作的结果无人问津，很有可能是死代码。另一个关键能力是 遍历（walk） 。MLIR 中的 IR 以操作树或区域（Region）的形式组织，Pass 通过 walk 接口按顺序访问每一个操作，把它们逐个丢进“标记→删除”的判定流程。

阿安终于明白：MLIR 里的 DCE 不是一个神秘魔法，而是一个“注册好的、会走路、会问话的打包 App”——它走遍每个角落，问清每件物品的用途。

流水线协同：和其他 Pass 打配合

问题来了。阿安发现，光靠 DCE 一个 Pass，行李箱还是不够整齐。因为死代码不是凭空出现的，很多是“兄弟 Pass 制造出来的”。

最典型的搭档是 CSE（公共子表达式消除）。CSE 干的事是把两段一模一样的计算合并成一段。打个比方：行李箱里有两包同样的压缩毛巾，CSE 会把它们合成一包，省出一份空间。但合并之后，原来第二包毛巾所在的位置就空出来了——而那条“多余的计算链”还没被清理掉。这时候 DCE 就该上场了：CSE 创造冗余，DCE 清扫冗余，两兄弟配合默契。

所以 DCE 在优化流水线中通常 放在中后期。前面的 Pass（如方言转换、常量折叠、CSE）负责“制造”和“暴露”冗余，DCE 负责“收尾”。如果把它放在最前面，它只能清掉最原始的一小撮死代码，后续其他 Pass 新产生的死代码就没人管了。

另一个朴素的真理是：一次 DCE 往往不够。编译优化的过程就像反复整理房间——你整理好了，家人又翻了东西出来，得再整理一遍。实践中，DCE 经常会被执行多轮，每轮之间穿插其他优化，直到 IR 的体积达到一个稳定的低点。

阿安感叹：“原来 Pass 之间不是各干各的，而是一条配合默契的流水线。DCE 是站在最后收拾残局的清道夫。”

价值与局限：行李箱变轻了，边界也清晰了

经过一轮轮优化，阿安终于看到了 DCE 的实在收益。行李箱从 26 公斤降到了 23 公斤：代码生成的指令更少了，后端编译器的工作量明显下降，寄存器的压力也小了很多。在大型模型编译中，哪怕只是把 3% 的死代码清掉，产出的目标代码体积和编译耗时都会有可感知的改善。

更重要的是，DCE 提升了整个编译器的可扩展性。有了 DCE 兜底，其他 Pass 可以放心大胆地生成“临时中间结果”——它们不需要担心自己制造的冗余会拖垮后端，因为 DCE 会在流水线末端把垃圾全部收走。这让每个优化模块的代码写起来更专注、更干净。

但阿安也撞上了 DCE 的边界：有副作用的操作，永远无法被 DCE 自动清除。就像那瓶安检禁止托运的辣椒水，虽然没人“用”它，但它属于危险品，不能扔。一个会打印日志、会写全局缓冲区的操作，即使它的返回值没有任何消费者，DCE 也会把它完整保留——因为删除它，可能就把“程序对外部世界说过的话”给抹掉了。

阿安在周会上分享战果：“DCE 让我明白，优化不是蛮力消除，而是深刻理解每一件物品存在的意义。该留的留，该扔的扔，边界画得清清楚楚。” 从此，他看整个优化流水线的眼光，都不一样了。

AI 应用场景

Python 演示

#!/usr/bin/env python3# -*- coding: utf-8 -*-"""模拟 MLIR 中死代码消除(DCE) Pass 的核心逻辑."""  class Operation:    """一个极简 IR 操作节点."""     def __init__(self, name, has_side_effect=False):        self.name = name        self.inputs = []          # 生产输入的操作(生产者)        self.users = []           # 消费本操作输出的操作(使用者)        self.has_side_effect = has_side_effect     def add_use(self, user):        self.users.append(user)  def erase_dead_code(ops, roots):    """从根集合开始反向标记, 删除未标记且无副作用的操作."""    marked = set()    stack = list(roots)    while stack:        op = stack.pop()        if op in marked:            continue        marked.add(op)        stack.extend(op.inputs)     kept, removed = [], []    for op in ops:        if op in marked or op.has_side_effect:            kept.append(op)        else:            removed.append(op)    return kept, removed  def build_sample_ir():    """构造一个小型计算图: 输出链 + 一条死代码分支."""    c1 = Operation("arith.constant 1")    c2 = Operation("arith.constant 2")    c3 = Operation("arith.constant 3")    mul = Operation("arith.mulf")    tanh = Operation("math.tanh")    log = Operation("math.log")     mul.inputs = [c1, c2]    tanh.inputs = [mul]    log.inputs = [c3]     c1.add_use(mul)    c2.add_use(mul)    c3.add_use(log)    mul.add_use(tanh)     ops = [c1, c2, c3, mul, tanh, log]    return ops, tanh  def main():    ops, root = build_sample_ir()    print("DCE 前 IR 操作数:", len(ops))    for op in ops:        print("  操作:", op.name, "| 使用者数:", len(op.users))     kept, removed = erase_dead_code(ops, [root])    print("DCE 后保留操作数:", len(kept))    print("DCE 删除死代码数量:", len(removed))    for op in removed:        print("  - 删除:", op.name)    print("最终输出 root 保留:", root in kept)  if __name__ == "__main__":    main()

1. class Operation:定义极简 IR 节点，用 inputs 记录生产者、users 记录消费者
2. def erase_dead_code(ops, roots):DCE 核心函数，从根集合开始反向标记
3. marked = set()建立空集合存放被标记保留的操作
4. stack = list(roots)用根操作（如最终输出 tanh）初始化工作栈
5. stack.extend(op.inputs)把当前操作的生产者压入工作栈，实现反向传播
6. if op in marked or op.has_side_effect:已标记或有副作用的操作必须保留
7. removed.append(op)其余操作计入死代码列表
8. build_sample_ir()构造包含死代码分支 log 的计算图
9. print("DCE 后保留操作数:", len(kept))输出清点结果

常见误区

面试题