想象一条汽车生产线：每一道工序都在改变车身布局——焊接机器人把车门装上、涂装车间喷上油漆、总装车间拧紧螺栓。可是如果每道工序做完后没人检查，“车门装歪了也照样流到下一站”，等整车下线才发现问题，返工成本早已不可估量。于是工厂在最关键的工位之间设置了质检员：他们对照图纸，快速确认“零件数量对不对、型号匹不匹配、装配是否符合规范”，一旦发现瑕疵立刻报告并拦截。 MLIR 的编译流水线就是这条生产线。每个 Pass（编译遍）都在对中间表示（IR）做加工：合并冗余算子、改换算子表示、调整数据布局。而 Pass 验证（Verification） 就是那位不知疲倦的质检员——在每个 Pass 执行之后，逐项检查 IR 是否仍然满足结构和语义约束，确保只有“合格品”才能流向下一个 Pass。本文将用“工厂质检”这个比喻贯穿始终，带你一步步看懂 Pass 验证的方方面面。
学会 Pass 验证机制，你就能在开发 AI 编译器的优化流程时快速定位“哪个 Pass 弄坏了 IR”，把编译错误从模糊的后果变成清晰的证据，这是构建可靠编译基础设施的核心技能。
目录
可视化演示
展示TVM编译框架中Pass验证检查IR结构与语义约束的机制、结构性验证/类型检查等多类验证的工作原理以及Pass验证在调试定位与CI回归中的应用场景，交互切换三种模式探索。
本节配有交互动效（进入视口后自动加载，约 3KB）。
'+CAPS.mode1+'
验证目标：守护编译流水线
工厂设立质检站不是为了找茬，而是为了让流水线能放心地高速转起来。每个车间工人只需要专注自己的工序，不必担心上一道工序把半成品弄坏——因为有人替他们守住了底线。MLIR 的 Pass Manager 正是这样：如果没有 Pass 验证，每个 Pass 的作者都得提心吊胆地检查别人留下的 IR，流水线的推进速度会被严重拖慢，错误也会层层积累。
在 MLIR 的世界里，一个 Pass 对 IR 的改写可能非常激进——合并冗余算子、把张量布局重排、将高维算子拆成低维算子。这些操作都会增删节点、改变节点之间的连线，而 IR 一旦被改坏，后续所有 Pass 都会在错误的输入上继续“加工”。Pass 验证的核心目标，就是让 IR 在每个 Pass 执行完成后仍然满足三件事：操作是合法的、类型是一致的、方言是规范的。
验证目标可以概括为一句话：让每一次变换后的 IR 都保持结构完整、语义可解释。这需要验证器确认 IR 没有因为 Pass 的误操作而变得不可信，也意味着一旦验证失败，我们就获得了“哪个 Pass 破坏了什么约束”的精确诊断线索。
回到生产线：验证器就是那道“质量闸门”——只有闸门亮绿灯，零件才能流向下一个工位。正是因为知道每一次变换后都会有这道闸门把关，编译器的各个 Pass 才有底气做更大胆的优化。
- 全称量词
$\forall \text{Pass } p$表示“对流水线中的每一个 Pass”，一个都不能例外 - 应用变换
$p\left(\text{IR}\right)$表示这个 Pass 对当前的中间表示执行改写 - 调用验证器
$\text{verify}(\cdot)$表示在变换后的 IR 上运行 Pass 验证器，逐项检查约束 - 结果断言
$= \text{true}$表示验证必须成功，一旦为 false 就触发错误处理路径
操作合法性：产品必须符合图纸
质检员拿起一个零件，第一件事就是对照图纸：这块冲压板应该有几个孔、每个孔的直径多大、孔的间距多少。图纸上没标注的孔，多打一个就是废品。MLIR 中每个操作（Op）的“图纸”就是它在方言里注册时的定义——用 TableGen 写明的操作数数量、结果数量、属性和区域结构。
Pass 验证中的操作合法性检查，就是在逐个核对 IR 里的每个 Op 是否符合它的设计图纸。验证器会检查：操作数个数与定义一致吗？每个操作数的类型落在合法类型集合里吗？结果数量和形状正确吗？如果 Op 自带区域（Region），区域内的块结构是否满足嵌套约束？任何一个不满足，这个 Op 就是“图纸之外的废品”。
图纸是生产质量的基准线。当一个 Pass 试图把两个类型完全不相干的节点焊接在一起时，验证器立刻就能看出“这不在图纸上”，并报警拦截。
- 验证器函数
$\text{verify}_{\text{Op}}$是某个操作 Op 对应的合法性验证函数 - 合取条件
$\bigwedge_{i=1}^{n}$表示“对所有操作数同时成立”，缺一不可 - 操作数类型
$\text{type}\left(\text{operand}_i\right)$取出第 i 个操作数的实际类型 - 类型集合归属
$\in \mathcal{T}_{\text{op}}$表示该类型必须落在此操作声明的合法类型集合中
类型一致性：零件规格必须匹配
发动机装上车架，靠的是法兰盘与安装孔精确配合；螺栓拧进螺母，粗细牙距必须一致。类型一致性就是 IR 世界里的“规格匹配”——操作数和结果之间的类型必须兼容，否则这个“装配体”就是不合格的。
在 MLIR 中，很多操作都有明确的类型约束。以加法操作为例，如果它声明了两个操作数和一个结果，那么三个东西的类型通常必须彼此一致：你不能让一个 f32 和一个 i32 相加，然后声称结果是 f32，这种“混搭”会在语义上造成灾难。验证器会检查操作数之间、操作数与结果之间的类型是否匹配，也会检查类型推断是否遵守了操作的声明。
类型一致性验证还包括更细致的内容：比如某个操作要求它的所有操作数拥有完全相同的元素类型，或者只允许标量与向量之间的广播组合。Pass 在改写 IR 时，如果错误地改变了一个节点的结果类型，却没有同步更新它的使用者的期望类型，验证器就会在类型一致性检查中把这个错误揪出来。
零件规格不匹配，硬装上车的结果不是异响，就是高速路上散架。类型一致性检查让 IR 在 Pass 之间传递时，永远带着“规格正确”的保证书。
- 类型验证器
$\text{verify}_{\text{type}}$表示类型一致性验证器 - 多条件合取
$\bigwedge_{i=1}^{n}$表示每一对操作数与结果都要满足条件 - 操作数类型
$\text{type}\left(\text{operand}_i\right)$获取第 i 个操作数的类型 - 类型相等判断
$= \text{type}\left(\text{result}_i\right)$和第 i 个结果的类型必须一致
方言规范：不同厂区各有规矩
一家大型工厂往往分多个厂区：冲压车间有自己的操作规范，涂装车间有严格的温湿度要求，总装车间有独立的线束标准。MLIR 的方言（Dialect） 就像是不同的厂区，每个方言定义了一批操作和类型，并附带了它们独有的使用规则。
方言规范验证检查的是：这个操作真的注册在它所属的方言里吗？方言是否是已知的、可解析的？操作的语义是否遵守了该方言自定义的约束？当一个方言的操作要嵌套在另一个方言的区域中时，这种跨方言的嵌套是否符合两边的约定？打个比方，涂装车间的工人不能把冲压车间的零件标准生搬硬套——每个方言都维护着属于自己的“厂规”，验证器必须按厂规来查。
厂规不是用来限制创造力的，而是让不同厂区的人协作时不打架。方言规范验证保证了跨方言优化时，每个操作都待在“懂它规矩”的地方。
- 方言验证器
$\text{verify}_{\text{dialect}}$是方言规范层面的验证函数 - 注册归属
$\text{Op} \in \text{Dialect}_{\text{reg}}$表示该操作必须属于某个已注册的方言 - 语义约束
$\text{semantic}_{\text{ok}}\left(\text{Op}\right)$表示操作的使用方式符合方言定义的语义 - 嵌套约束
$\text{nest}_{\text{ok}}\left(\text{Op}\right)$表示操作在区域和块中的嵌套方式满足各方言间的协作约定
验证机制：质检员的工作流程
质检员不是随机抽查，而是有一套固定的工作节奏：什么时候来、查哪些项目、查完怎么记录、不合格怎么上报。MLIR 的验证机制同样有着清晰的工作流程，它由 verify() 方法、自动调用时机 和 失败处理流程 三部分构成。
首先，每个可验证的对象——操作、区域、块、乃至整个 IR——都可以实现 verify() 方法。MLIR 内置的验证器会先做通用的结构检查（比如类型系统是否正常、操作数列表是否完整），然后调用操作自己的 verify() 方法，执行方言或操作特有的自定义规则。其次，Pass Manager 在配置了 -verify-each 选项时，会在每个 Pass 执行完后自动运行一次完整验证，确保 IR 在流水线的每一站都合格。
如果验证失败，验证器并不会把 IR 强行纠正过来，而是产出一条诊断错误，指明“哪个操作、在哪个 Pass 之后、违反了哪条约束”。Pass Manager 收到失败信号后，会中止当前 Pass 的执行路径，把流水线切换进错误处理模式，开发者随后就能顺着错误日志精确定位问题。
质检员的工作流程保证了“每道工序后必有检查、每次检查必有记录、每个不合格品必有上报”。有了这套流程，编译流水线才能从“各干各的”变成“协同作战”。
- 变换前表示
$\text{IR}_k$表示流水线第 k 步的中间表示，即 Pass 的输入 - 变换应用
$\text{Pass}_k(\cdot)$执行第 k 个 Pass 的改写逻辑 - 验证器接入
$\text{verify}(\cdot)$对 Pass 的输出立即执行完整验证 - 变换后表示
$\text{IR}_{k+1}$表示通过验证后进入下一步的合法表示
工程价值：质检体系的价值
质检体系最容易被低估的价值，恰恰是它“什么都没修”——因为它，事故在萌芽期就被掐灭了。Pass 验证对编译器的工程价值也是如此：它不像一个优化 Pass 那样让代码变快，但它让“错误不在流水线中潜伏”这件事变得可预期、可控制。
具体来说，验证带来的第一重价值是编译器可靠性。一条包含几十个 Pass 的流水线，任何一个 Pass 的误操作如果被带到最后，生成的就是一段损坏的机器码；有了验证，问题会在发生的那一站就被拦截。第二重价值是调试辅助：错误信息精确到违规的操作和违反的规则，开发者不需要从最终产物倒推是哪一步出了错。第三重价值是优化效果保障：每个 Pass 都拿到合法输入，优化结果才可预期、可复现。第四重价值是开发者友好：清晰的错误报告让编译器的使用者（比如模型部署工程师）也能快速定位问题，而不是在无穷的编译日志里抓瞎。
质检员的价值不在于“修好了多少零件”，而在于“拦住了多少本该报废的产品”。Pass 验证用最小的运行时开销，为编译器的正确性买了一份额度最划算的保险。
- 验证开销
$C_{\text{verify}}$表示每次验证消耗的编译时间与资源 - 远小于号
$\ll$表示左边远小于右边，强调量级上的差距 - 事后调试成本
$C_{\text{debug}}$表示错误 IR 流入后续 Pass 后，定位和修复问题的代价 - 错误代码成本
$C_{\text{wrong-code}}$表示错误代码生成后引发的上线事故、排查和赔偿等损失
AI 应用场景
AI 编译器算子融合开发
阶段：后端优化与验证
解决的问题：开发张量算子融合 Pass 时，融合逻辑经常破坏操作数和结果之间的类型一致性，传统做法是“写完整个流水线后统一调试”，错误来源模糊。
具体案例：某 AI 编译器团队的工程师正在为 GPU 编写一个把多个 element-wise 算子融合成单个 kernel 的 Pass。融合后 IR 中的新 op 需要满足所有输入输出张量形状一致。开启 -verify-each 后，验证器在融合 Pass 后立即发现一个张量形状不匹配的操作，并精确报告是融合逻辑中索引计算错误。工程师把问题从“跑 20 个 Pass 后的崩溃”缩小到“单步验证日志中的一条错误”，半天内修复。
深度学习模型部署转换验证
阶段：模型转换与中间表示生成
解决的问题：将 PyTorch/TensorFlow 模型转换到 MLIR 方言时，转换脚本可能遗漏某些操作的约束，导致下游代码生成错误。
具体案例：部署工程师把训练好的 Transformer 模型转换为 MLIR 方言时，一个来自源框架的自定义注意力算子被映射成了不兼容的方言操作。Pass 验证在转换后的 IR 上运行方言规范检查，发现该操作非法融合了两种方言的语义规则。验证错误信息直接指出问题操作及其所在方言，部署工程师据此修正了映射表，模型顺利通过后续的量化与代码生成。
自定义 AI 算子方言构建
阶段：方言扩展与自定义验证
解决的问题：为专用 AI 芯片（NPU/TPU）定义自定义方言时，普通默认验证无法覆盖硬件特有的约束，容易生成无法执行的低效代码。
具体案例：硬件编译器团队为某 NPU 定义了一套自定义方言，其中的“矩阵乘加”算子要求两个输入矩阵的 K 维度必须相等。团队在 Op 定义中重写了 verify() 方法，把这条规则写入验证逻辑。此后，任何 Pass 只要生成了 K 维度不匹配的该算子，验证器都会立即报错。这让芯片后端在集成第三方 Pass 时能够安全地拒绝非法 IR，保障了硬件执行正确性。
Python 演示
class OpDef: """模拟 MLIR 中的操作定义（类似 TableGen 定义）""" def __init__(self, name, operand_count, operand_types, result_type): self.name = name self.operand_count = operand_count self.operand_types = operand_types # 允许的输入类型集合 self.result_type = result_type # 允许的结果类型集合 class Op: """模拟 IR 中的一个操作节点""" def __init__(self, op_def, operands): self.op_def = op_def self.operands = operands # 每个操作数的实际类型 @property def name(self): return self.op_def.name class Verifier: """Pass 验证器：检查操作合法性、类型一致性""" def __init__(self): self.errors = [] def verify(self, op): self.errors.clear() self._verify_operand_count(op) self._verify_operand_types(op) return len(self.errors) == 0 def _verify_operand_count(self, op): if len(op.operands) != op.op_def.operand_count: self.errors.append( "%s: 期望 %d 个操作数，实际 %d 个" % (op.name, op.op_def.operand_count, len(op.operands)) ) def _verify_operand_types(self, op): for i, t in enumerate(op.operands): if t not in op.op_def.operand_types: self.errors.append( "%s: 操作数 %d 类型 %s 不合法" % (op.name, i, t) ) def fuse_pass(ops): """模拟一个融合 Pass：将两个 add 合并为一个 fused_add""" if len(ops) < 2: return ops a, b = ops[0], ops[1] if a.name == "add" and b.name == "add" and a.operands == b.operands: fused_def = OpDef("fused_add", 2, ["f32", "f32"], "f32") return [Op(fused_def, ["f32", "f32"])] + ops[2:] return ops def main(): add_def = OpDef("add", 2, ["f32", "f32"], "f32") sub_def = OpDef("sub", 2, ["f32", "f32"], "f32") ir = [ Op(add_def, ["f32", "f32"]), Op(add_def, ["f32", "f32"]), Op(sub_def, ["f32", "i32"]), # 类型非法，应被验证器发现 ] verifier = Verifier() print("=== 原始 IR 验证 ===") for op in ir: ok = verifier.verify(op) print("%-12s 验证" % op.name, "通过" if ok else "失败") for e in verifier.errors: print(" ->", e) print("\n=== Pass 变换后验证 ===") new_ir = fuse_pass(ir) for op in new_ir: ok = verifier.verify(op) print("%-12s 验证" % op.name, "通过" if ok else "失败") for e in verifier.errors: print(" ->", e) if __name__ == "__main__": main()
OpDef("add", 2, ["f32", "f32"], "f32")定义 add 操作的“图纸”：2 个操作数、类型必须是 f32、结果是 f32Op(sub_def, ["f32", "i32"])构造一个类型非法的 sub 操作，模拟 Pass 误改类型后产出的坏节点verifier.verify(op)对每个操作运行验证器，返回 True/False 表示验证是否通过self.errors.clear()每次验证前清空错误日志，避免上一次的报错残留影响结果fuse_pass(ir)模拟一个融合 Pass：把两个可融合的 add 合并成一个 fused_addif t not in op.op_def.operand_types:核心的类型合法性检查：实际类型必须属于操作定义允许的类型集合
常见误区
误区“我的 Pass 执行完了一点没报错，那中间表示肯定是合法的吧？Pass 本身没抛异常，说明变换没问题。”
正解工序结束不等于产品合格。Pass 能执行完只代表它自己的 C++ 逻辑没有崩溃，不代表它生成的 IR 满足操作合法性、类型一致性等约束。就像焊接机器人把车门焊上去了，不代表车门就对得齐。MLIR 需要显式启用 -verify-each 或在 PassManager 中配置验证，才会在每个 Pass 之间做完整检查；不配置验证，Pass 的错误就会被下游 Pass 继承并放大。
为何常见：初学者习惯把“程序运行成功”等同于“结果正确”，忽略了编译工具自身也可能出错，且编译器不会默认在每个 Pass 后做完整验证。
误区“验证每个 Pass 都要跑一遍，太慢了，正式发布版本应该把验证全部关掉，我只在调试时开。”
正解编译器最重要的使命是产出正确代码。验证的时间开销通常是毫秒级，而错误 IR 流入后续 Pass 后，定位问题可能花掉几个小时甚至几天。工厂质检员花 5 秒检测一个零件，总比整车装配完再返工划算。即便在追求编译速度的发布构建中，也应保留验证，或至少保留 -verify-each 这种关键验证，而不是全部关闭。
为何常见：性能直觉只看到验证的“额外时间”，却忽略了编译错误带来的更大时间与信任成本。
误区“MLIR 自带验证能力，我自定义的 Op 注册后会自动被验证所有规则，不用写 verify() 方法。”
正解MLIR 提供的通用验证只覆盖基础设施层面的检查（如类型系统正常、操作数列表完整）。但每个算子特有的语义约束——比如“add 的两个操作数必须同一精度”“矩阵乘加的 K 维度必须匹配”——必须由开发者在自己的 Op 定义中通过重写 verify() 方法来实现。用比喻说，国家有通用安全法规，但食品厂还要自己制定车间卫生细则。自定义方言/操作不写 verify()，就等于没有质检标准的厂区。
为何常见：不清楚“框架通用验证”与“自定义验证”的分工边界，误以为注册即自动获得完整验证覆盖。
误区“我的 IR 通过了所有验证，说明优化已经做到最好了，没必要再调整。”
正解验证只回答“IR 是否符合约束”，不回答“IR 是否是最佳表示”。它是一张及格证，不是满分奖状。质检员只能确认零件符合图纸，无法判断这个设计在市场上有竞争力。优化效果好不好，要依赖专门的性能分析、基准测试和成本模型来判断。Pass 验证是质量门槛，不是优化终点。
为何常见：把“正确性”与“最优性”混为一谈，以为通过验证就等于达到优化目标。
面试题
Q1. Pass 验证的核心目标是什么？
- A.提升 Pass 执行的整体效率
- B.保证 IR 满足结构与语义约束← 正确答案
- C.压缩中间表示的存储空间
- D.提升操作系统的运行性能
答案：B。Pass 验证的目的是确保每个 Pass 执行后 IR 仍满足结构合法、类型一致、方言规范等约束。A 和 C 是性能优化方向，D 与编译器无关，所以选 B。
Q2. MLIR 中默认谁负责触发 Pass 验证？
- A.由使用编译器的终端用户主动触发
- B.由 PassManager 在每个 Pass 后触发← 正确答案
- C.由操作系统依据调度规则而触发
- D.由外部硬件基础设施随时进行监测
答案：B。Pass Manager 是编译流水线的调度者，它负责在 Pass 执行后触发验证逻辑（配合 -verify-each 配置）。终端用户、操作系统和硬件都不直接参与 Pass 验证的调度。
Q3. 验证中“操作合法性”检查的核心是？
- A.操作结果的名称和注释的格式
- B.代码作者名称与修改日期记录
- C.操作数与结果的个数及类型匹配← 正确答案
- D.编译目标平台的架构与指令集合
答案：C。操作合法性检查操作数和结果的个数、类型是否符合操作定义（图纸）。A、B 是风格信息，D 是平台信息，都不属于操作合法性的验核范围。
Q4. 类型一致性验证侧重检查？
- A.操作数类型与计算结果类型匹配← 正确答案
- B.源代码文件的编码格式是否统一
- C.编译日志的级别设置是否正确
- D.链接库的版本号是否保持稳定
答案：A。类型一致性的核心是操作数与结果之间的类型兼容。B、C、D 分别是编码、日志和链接配置问题，与 IR 节点内部的类型约束无关。
Q5. 自定义 Op 应如何接入 Pass 验证？
- A.重写该 Op 的 verify 方法← 正确答案
- B.修改 PassManager 的全局配置
- C.用脚本实现正则匹配规则
- D.无需做任何额外的实现处理
答案：A。自定义 Op 通过重写 verify() 方法声明自身特有的合法性规则，这是 MLIR 的标准扩展点。改 PassManager 配置、用正则脚本都不是接入验证的正确方式。
Q6. verify-each 选项的作用是？
- A.每个 Pass 执行完成后都进行验证← 正确答案
- B.只验证整个流水线的最后阶段
- C.跳过验证直接编译输出结果
- D.仅当开发者输入参数时才验证
答案：A。-verify-each 让 PassManager 在每个 Pass 执行完成后都运行一次完整验证，使错误在产生的瞬间就被发现，而不是等到流水线末尾。
Q7. 当 Pass 验证失败时，以下处理方式最合理的是？
- A.主动弃用整个编译流水线
- B.检查错误日志定位有害 Pass← 正确答案
- C.忽略错误并继续执行后续 Pass
- D.重新安装编译器再执行一次
答案：B。验证失败意味着某个 Pass 弄坏了 IR。正确做法是读取验证器生成的诊断信息，定位是哪个 Pass、哪个操作违反了哪条约束，然后修复该 Pass。忽略错误会放大错误，弃用整个流水线和重装编译器都是过激且无效的。
Q8. Pass 验证无法发现以下哪些错误？
- A.语义正确但形式不匹配的 IR← 正确答案
- B.操作数与结果类型不匹配
- C.代码目标平台的优化不到位← 正确答案
- D.方言规则未被正确满足
答案：AC。验证能发现类型不匹配（B）和方言违规（D），但无法发现“形式上合法但语义实际错误”的 IR，因为它是基于结构约束而非运行时语义。验证也衡量不了优化是否到位，那是性能分析的工作。
Q9. 方言规范验证包含哪些方面？
- A.操作已正确注册到所属方言← 正确答案
- B.嵌套操作符合方言的约束← 正确答案
- C.操作语义满足该方言的定义← 正确答案
- D.源代码注释包含了作者姓名
答案：ABC。方言规范验证涵盖注册归属、嵌套约束和语义符合性。注释内容属于代码风格管理，不是 IR 验证的内容。
Q10. 关于验证与编译器可靠性的说法正确的有？
- A.验证可以及时发现 Pass 引入的错误← 正确答案
- B.验证完全替代单测和集成测试
- C.自定义 Pass 更需要验证保护流水线← 正确答案
- D.验证保证 IR 总是最优的表示
答案：AC。验证能即时发现 Pass 引入的结构错误（A），自定义 Pass 缺少社区验证，更需要保护（C）。但验证不能替代单测/集成测试，因为它只查结构约束；验证也不保证最优性（D），那是性能分析的目标。