图优化：自定义方言设计实践

可视化演示

演示MLIR自定义方言设计：多层IR逐级lowering、ODS操作定义到C++代码生成，以及Pattern Rewriting重写规则，支持步进切换与参数调节。

需求分析定位

快递公司不会因为一个客户说“我想寄螃蟹”就立刻买一百辆冷链车。运营会先翻数据：现有常温线路能覆盖多少、客户愿意为保鲜多付多少钱、周边城市有没有可借用的冷链资源。同样的，在 MLIR 里“造一个方言”最忌拍脑袋。动手写代码前，得先回答三个问题：领域里有哪些独一无二的概念？现有通用 IR 表达这些概念时哪里难受？目标硬件希望我们用什么样的方式描述计算？

这三个问题分别对应方言的三大价值。第一，领域概念的直接表达：把“卷积”写成若干 reshape 和 dot 的组合，不如直接写一个 conv2d 让人一眼看懂，编译器也更容易抓住融合与复用机会。第二，通用 IR 的局限：builtin 方言只有最基础的类型和操作，无法表达“这个张量的物理布局是 NHWC”或“这个算子必须在 DMA 引擎上执行”。第三，硬件特征的抽象：芯片的寄存器、内存层次、并行单元，都需要方言提供“离家门口最近”的一层描述。

实践中，人们常用一份简短的评估清单来启动方言项目：列出候选操作集、估计每个操作为优化器带来的收益、对比用通用方言拼凑要付出的重写成本。收益越高、成本越低，就越值得立项。这几项权衡可以量化为一个价值公式：

就像冷链专线的开通论证报告，公式里的每一项都对应着真实投入：表达力是客户愿意付的保价费，优化潜力是少损耗一箱蟹的利润，硬件匹配是让车队不空跑的前提。三项加权得分高，才值得立项动工。

方言骨架搭建

冷链专线立项后，第一步不是买蟹，而是定规矩：库区叫“冷一区”、工牌戴蓝帽、面单前缀加“LL“。这些看似琐碎的规矩，让每个员工在交接时不用猜对方在说什么。MLIR 里搭建方言骨架也是同理：明确命名空间、声明依赖、组织文件、注册进上下文——一套”工牌与编码体系”。

MLIR 的方言是一个 C++ 对象，通过继承 mlir::Dialect 创建，并注册到 MLIRContext 这个“总登记台”。命名规范要求方言名小写开头、不含特殊字符，操作名统一为“方言名。操作名”。依赖声明告诉编译器：本方言用到了 builtin 或其他自定义方言的哪些类型、属性和接口，从而构筑一张清晰的依赖网，避免循环引用。

通常一个方言项目包含 TableGen 声明文件（ODS）、C++ 实现文件和 CMake 构建脚本。ODS 文件用声明式语言描述操作、类型、属性，自动生成 C++ 类与解析打印代码——这就像先把各岗位的 SOP 写成手册，再统一翻译成培训课程。方言的完整名称也有固定格式：

工牌、编码、手册都齐了，冷链专线才算有了“身份”。方言骨架搭好，后续的操作和类型定义才有安放之处，团队协作效率也会大幅提升。

操作定义规范

快递公司每开一条新业务线，都要给一线员工发一份详细的操作手册：接到活蟹单先核验保价、装冰袋要放底层、面单必须贴在外箱右上角。MLIR 的自定义方言同样需要把“业务动作”定义得明明白白——操作（Operation）就是方言世界里的业务动作。

每个操作有操作数（输入物料）、结果（产出）、属性（参数）和区域（子过程）。操作数对应包裹物料，结果是加工后的产出，属性是“冰袋数量”“温控模式”这类静态参数。MLIR 的 ODS 框架允许用声明式写法定义这些元素，并为操作标注特性，如“无副作用”“可交换”等，让优化器敢大胆做变换。

操作名必须唯一，格式是“方言名。操作名”；操作数数量、每个操作数的类型、结果的数量都应在定义中声明；操作验证逻辑保证不合法的调用在构造阶段就被拦截，而不是等到代码生成后崩溃。操作合法性可以表达为一条逻辑约束：

操作手册写得细，交接就不会出错。同理，操作定义得严谨，后续的降级和优化才能在稳固的地基上盖楼。

类型系统设计

冷链业务里，“活蟹”和“冰鲜鱿鱼”不能混放。光靠操作手册还不够，得有一套标签体系：保温箱上贴着不同的温度等级贴纸，分拣机才能自动分流。在 MLIR 中，这套贴纸就是类型系统。

自定义类型用于约束操作数的语义。操作数不能只看成“张量”或“整数”，还要表达“这是一张 NHWC 布局的量化张量”或“这是一个分布在多卡上的分块张量”这类深层信息。类型可以在 ODS 中用 TypeDef 声明，并携带参数，如形状、元素类型、布局方式。

类型参数要定义编码、解析和打印三件事：怎样存进内存、怎样从文本读出来、怎样展示给人看。类型约束校验则保证只有语义匹配的类型才能连到同一个操作上，等于分拣机只认贴对的标签。类型占用的存储空间可以这样计算：

标签贴对，分拣效率才高；类型定义得好，整个流水线就能在编译期把“不可混放”的错误拦截下来，而不是等包裹送到客户手上才被发现。

降级转换实现

冷链车到了城市转运中心，能不能直接开进每个小区？不能。你需要在转运点把活蟹从泡沫箱里取出，套上保温袋、放进社区冷链柜，重新打印一张末端配送面单。这个过程，就是编译器里的“降级”（Lowering）。

降级把高层方言操作替换成低层方言操作组合，是自定义方言与现有工具链对接的必经之路。MLIR 提供了一套声明式机制：ConversionTarget 声明“哪些方言最终要留下来”，RewritePattern 定义“每个操作如何被拆解替换”，Pass 驱动整体转换的工序。

开发者在 ConversionTarget 中标记不合法（要被替换）的操作，在 RewritePattern 中实现“匹配 + 重写”两个动作，最后通过 Pass 运行“部分转换”或“完全转换”流水线。匹配失败时操作会被保留，并通过诊断信息提示开发者补全规则。降级可以抽象为一级一级的翻译：

拆包重装的动作越标准，末端配送越顺畅；降级规则写得越完整，高层模型就越能顺利落到各类硬件指令上。

架构匹配适配

同样是冷链运输，长途干线用重型冷冻车，同城急送用保温三轮车，小区投递用冷链柜。不同的车有不同装载和行驶特性，专线的设计必须因车而异——这就是硬件匹配。

自定义方言的最后归宿通常是特定硬件：GPU、NPU 或 DSP。方言分层（如高层算子方言 → 循环/向量方言 → LLVM 方言）可以看作车队里不同车型的调度体系。为了让硬件跑得最快，方言设计需要显式表达并行度、内存布局和访存模式。

硬件感知的优化贯穿其中：算子融合把多次访存合并成一次，向量化利用计算单元的宽度，内存布局控制把数据排布成硬件最顺手的形状。方言能否表达这些信息，直接决定优化器能做到多好。最终的执行耗时可以建模为：

车型和货物匹配，整条运输链才最高效；方言和硬件特征匹配，模型才能在芯片上榨出每一分算力和带宽。

集成验证测试

冷链专线全线铺通，不能直接宣布“开业”。你得先跑几十票测试货，跟踪每一票的温控记录和送达时间，再和普通线路对比，最后才敢接大客户的单。方言落地的后半程，就是集成、验证、迭代。

新方言要注册进 MLIRContext，作为转换 Pass 挂入编译流水线，和已有的 tensor、linalg、llvm 等方言协同工作。MLIR 提供 mlir-opt 工具，开发者可以编写文本 IR 测试用例，验证方言的解析、打印、验证、降级行为是否正确。

功能测试用 FileCheck 断言 IR 转换结果；集成测试把自定义方言放进完整的“前端图 → 高层方言 → 低层方言 → LLVM IR”流水线；性能测试则和基准路径对比，算出加速比：

只有跑过压力测试的冷链线，才敢承诺“死蟹包赔”；只有经过完整验证的方言，才值得交付给生产环境。这条专线从此正式并入物流大网，成为整个分拨中心能力的一部分。

AI 应用场景

Python 演示

class Operation:    """模拟 MLIR 中的操作节点"""     def __init__(self, dialect, op_name, operands, attrs=None):        self.dialect = dialect        self.op_name = op_name        self.operands = list(operands)        self.attrs = attrs or {}     def full_name(self):        # 方言前缀 + 点号 + 操作名，例如 toy.silu        return "{0}.{1}".format(self.dialect, self.op_name)     def __repr__(self):        operands_repr = ", ".join(o.full_name() for o in self.operands)        return "{0}({1})".format(self.full_name(), operands_repr)  class Dialect:    """模拟 MLIR 方言命名空间"""     def __init__(self, name):        self.name = name     def __repr__(self):        return self.name     def make(self, op_name, operands, attrs=None):        return Operation(self, op_name, operands, attrs)  def lower_silu(op, dialect):    """把 toy.silu 降级为 sigmoid(x) * x 两个操作"""    x = op.operands[0]    sigmoid = dialect.make("sigmoid", [x])    mul = dialect.make("mul", [x, sigmoid])    return [sigmoid, mul]  def lower_toy_to_std(toy_ops, std_dialect):    """自定义方言 -> 基础方言的降级流水线"""    lowered_ops = []    for op in toy_ops:        if op.op_name == "silu":            lowered_ops.extend(lower_silu(op, std_dialect))        else:            lowered_ops.append(op)    return lowered_ops  def main():    toy = Dialect("toy")    std = Dialect("std")    x = std.make("input", [], {"name": "x"})    silu = toy.make("silu", [x])    graph = [x, silu]    print("降级前:", graph)    result = lower_toy_to_std(graph, std)    print("降级后:", result)  if __name__ == "__main__":    main()

1. class Operation:表述 MLIR 中的操作节点，记录归属方言、操作名、操作数和属性。
2. return "{0}.{1}".format(self.dialect, self.op_name)拼接“方言名。操作名”的完整唯一名称。
3. def lower_silu(op, dialect):定义一个降级规则，对应 MLIR 里的 RewritePattern。
4. sigmoid = dialect.make("sigmoid", [x])创建第一个基础操作，把原操作数传进去。
5. mul = dialect.make("mul", [x, sigmoid])创建第二个基础操作，组合成 x * sigmoid(x)。
6. if op.op_name == "silu":模式匹配阶段，判断当前操作是否命中降级规则。
7. lowered_ops.extend(lower_silu(op, std_dialect))把单个高层操作展开为多个基础操作，加入结果列表。
8. if __name__ == "__main__":提供可执行入口，运行后能直接看到降级前后 IR 的变化。

常见误区

面试题