破茧成蝶的前奏深入浅出编译器的骨架——抽象语法树AST在全线洗劫了 MLIR 框架、底层方言以及各种硬核的 Pass 优化之后我们需要将目光暂时从编译器的“中后端”移回一切故事开始的地方——前端Frontend。无论是手写一段 C 算法、在 PyTorch 里搭一个神经网络还是编写一段 MLIR 的 TableGen 文件编译器拿到的第一手原料永远是人类手写的、冰冷的纯字符串文本。编译器是如何把一团毫无结构的字符变成其内存里可操作的、具备高级语义的图结构的这期间最关键的桥梁与核心产物就是ASTAbstract Syntax Tree抽象语法树。1. 什么是抽象语法树ASTAST 是源代码语法结构的一种抽象抽象抽象的树状表现形式。当你在高级语言里写下一行复杂的数学公式或者条件分支时前端的词法分析器Lexer会先把它切成一个个有意义的单词Tokens随后语法分析器Parser会根据语言的文法规则如上下文无关文法 Backus-Naur Form将这些零散的单词拼装成一棵具有嵌套层级关系的树。为什么被称为“抽象”的因为它过滤掉了源码中所有与计算语义无关的表象细节。例如你代码里写了多少个空格、换行符、注释——扔掉。你有没有在外层多套几层无意义的括号((a b))——无视只保留加法本质。分号和逗号等纯语法的标点符号——剔除用树的分支结构直接表达。最终留在树上的全是纯粹的“语义骨架”如算术节点、变量引用、函数调用。2. 经典案例一行代码在 AST 里的物理长相为了让树的形态完全可视化我们来看一行最简单的现代数学表达式xab*2;当这段字符穿过编译器的 Parser 之后它在内存中所建立的 AST 树状拓扑关系如下[AssignmentExpr] (赋值表达式) / \ [Variable] [BinaryOperator] (二进制加法算子) (x) / \ [Variable] [BinaryOperator] (二进制乘法算子) (a) / \ [Variable] [Constant] (b) (2)树的求值与优先级自对齐注意到没有虽然在代码文本中加号写在前面但因为乘法*的优先级更高AST 在构建时自动将b * 2沉到了树的最深处。在编译器后续遍历这棵树时它会遵循后序遍历从底向上的逻辑先计算最底层的b * 2再将结果与a相加最后把最终结果灌入左侧的x。语法的优先级在树的拓扑结构确立的那一刻就已经被物理固化了。3. AST 在传统编译器 vs. 现代 MLIR 生态中的不同宿命在不同的编译器流派里AST 的生命周期和地位有着天壤之别传统的“短命”AST如经典 GCC / Clang在传统的编译器栈里AST 往往只是前端的一个瞬时产物。Clang 读入 C 源码在内存中拉起一棵庞大的 AST做完基础的类型检查Type Checking和语义校验后就会迫不及待地调用生成器把这棵树彻底打碎、坍缩成扁平的一维通用中间表示如纯低级的 LLVM IR。在传统的后端 Pass 优化如 CSE看来AST 早已是一具尸体。MLIR 生态下的“终身”AST 映射MLIR 的出现彻底颠覆了 AST 只能作为前端临时工的悲惨命运。在 MLIR 架构中高级方言如tosa、stablehlo本身就具备极其强悍的高维语义保留能力。当我们将高级语言编译进 MLIR 时我们会将 AST 直接、一比一地平移和转译为 MLIR 的高层算子图Op Graph。例如AST 中的AssignmentExpr节点会被直接映射为 MLIR 的 SSA 赋值语义而树上的数学运算节点则会完美蜕变为tosa.add或arith.addf。在 MLIR 中AST 的神魂从未消亡它只是换了一种更严谨、更具可扩展性的 Op 拓扑形态继续活着。4. 开发者如何操纵 ASTAST 变动与 Pass 桥梁作为编译器或者高级中间件的研发人员如果你需要实现一些极为靠前的高级功能例如给语言写一个自动格式化工具 Lint、或者是写一个将 Python 代码自动翻译成 MLIR 方言的编译器前端转换器你就必须掌握操纵 AST 的绝活。在 C 中由于 AST 是高度嵌套的树遍历它的工业标准模式是Visitor访问者模式。// 模拟一个编译器前端的 AST 转换器classMLIRGenVisitor:publicASTVisitor{public:// 1. 当遍历到 AST 的二进制操作节点时触发mlir::ValueVisitBinaryOp(BinaryOpASTNode*node){// 递归去啃左子树和右子树把它们先变成 MLIR 认可的 Valuemlir::Value lhsVisit(node-getLHS());mlir::Value rhsVisit(node-getRHS());// 2. 根据 AST 节点的类型直接用 MLIR 的 OpBuilder 在内存中物理组装对应的底层方言 Opif(node-getOpType()OpType::ADD){returnbuilder.createmlir::arith::AddFOp(node-getLocation(),lhs,rhs);}// ...}};这段 C 逻辑就是现代 AI 编译器前端如从 TorchScript 树到 MLIR的核心翻译逻辑。它像一台织布机将树状的抽象语法骨架源源不断地编织成 MLIR 高速公路上跑的高性能 SSA 数据流。总结如果说 MLIR 的底层的各种方言LLVM, NVVM是编译器伸向物理硬件的强壮触角那么 AST 就是编译器拥抱人类智慧的第一道视网膜。它成功将主观的代码文本提炼为客观的数学拓扑结构。只有深刻理解了 AST 是如何将高级语言的逻辑进行结构化收纳的你在后续手写 MLIR 前端转换器或设计高级算子方言时才能准确拿捏高级语义与底层指令之间的完美平衡。
破茧成蝶的前奏深入浅出编译器的骨架——抽象语法树AST在全线洗劫了 MLIR 框架、底层方言以及各种硬核的 Pass 优化之后我们需要将目光暂时从编译器的“中后端”移回一切故事开始的地方——前端Frontend。无论是手写一段 C 算法、在 PyTorch 里搭一个神经网络还是编写一段 MLIR 的 TableGen 文件编译器拿到的第一手原料永远是人类手写的、冰冷的纯字符串文本。编译器是如何把一团毫无结构的字符变成其内存里可操作的、具备高级语义的图结构的这期间最关键的桥梁与核心产物就是ASTAbstract Syntax Tree抽象语法树。1. 什么是抽象语法树ASTAST 是源代码语法结构的一种抽象抽象抽象的树状表现形式。当你在高级语言里写下一行复杂的数学公式或者条件分支时前端的词法分析器Lexer会先把它切成一个个有意义的单词Tokens随后语法分析器Parser会根据语言的文法规则如上下文无关文法 Backus-Naur Form将这些零散的单词拼装成一棵具有嵌套层级关系的树。为什么被称为“抽象”的因为它过滤掉了源码中所有与计算语义无关的表象细节。例如你代码里写了多少个空格、换行符、注释——扔掉。你有没有在外层多套几层无意义的括号((a b))——无视只保留加法本质。分号和逗号等纯语法的标点符号——剔除用树的分支结构直接表达。最终留在树上的全是纯粹的“语义骨架”如算术节点、变量引用、函数调用。2. 经典案例一行代码在 AST 里的物理长相为了让树的形态完全可视化我们来看一行最简单的现代数学表达式xab*2;当这段字符穿过编译器的 Parser 之后它在内存中所建立的 AST 树状拓扑关系如下[AssignmentExpr] (赋值表达式) / \ [Variable] [BinaryOperator] (二进制加法算子) (x) / \ [Variable] [BinaryOperator] (二进制乘法算子) (a) / \ [Variable] [Constant] (b) (2)树的求值与优先级自对齐注意到没有虽然在代码文本中加号写在前面但因为乘法*的优先级更高AST 在构建时自动将b * 2沉到了树的最深处。在编译器后续遍历这棵树时它会遵循后序遍历从底向上的逻辑先计算最底层的b * 2再将结果与a相加最后把最终结果灌入左侧的x。语法的优先级在树的拓扑结构确立的那一刻就已经被物理固化了。3. AST 在传统编译器 vs. 现代 MLIR 生态中的不同宿命在不同的编译器流派里AST 的生命周期和地位有着天壤之别传统的“短命”AST如经典 GCC / Clang在传统的编译器栈里AST 往往只是前端的一个瞬时产物。Clang 读入 C 源码在内存中拉起一棵庞大的 AST做完基础的类型检查Type Checking和语义校验后就会迫不及待地调用生成器把这棵树彻底打碎、坍缩成扁平的一维通用中间表示如纯低级的 LLVM IR。在传统的后端 Pass 优化如 CSE看来AST 早已是一具尸体。MLIR 生态下的“终身”AST 映射MLIR 的出现彻底颠覆了 AST 只能作为前端临时工的悲惨命运。在 MLIR 架构中高级方言如tosa、stablehlo本身就具备极其强悍的高维语义保留能力。当我们将高级语言编译进 MLIR 时我们会将 AST 直接、一比一地平移和转译为 MLIR 的高层算子图Op Graph。例如AST 中的AssignmentExpr节点会被直接映射为 MLIR 的 SSA 赋值语义而树上的数学运算节点则会完美蜕变为tosa.add或arith.addf。在 MLIR 中AST 的神魂从未消亡它只是换了一种更严谨、更具可扩展性的 Op 拓扑形态继续活着。4. 开发者如何操纵 ASTAST 变动与 Pass 桥梁作为编译器或者高级中间件的研发人员如果你需要实现一些极为靠前的高级功能例如给语言写一个自动格式化工具 Lint、或者是写一个将 Python 代码自动翻译成 MLIR 方言的编译器前端转换器你就必须掌握操纵 AST 的绝活。在 C 中由于 AST 是高度嵌套的树遍历它的工业标准模式是Visitor访问者模式。// 模拟一个编译器前端的 AST 转换器classMLIRGenVisitor:publicASTVisitor{public:// 1. 当遍历到 AST 的二进制操作节点时触发mlir::ValueVisitBinaryOp(BinaryOpASTNode*node){// 递归去啃左子树和右子树把它们先变成 MLIR 认可的 Valuemlir::Value lhsVisit(node-getLHS());mlir::Value rhsVisit(node-getRHS());// 2. 根据 AST 节点的类型直接用 MLIR 的 OpBuilder 在内存中物理组装对应的底层方言 Opif(node-getOpType()OpType::ADD){returnbuilder.createmlir::arith::AddFOp(node-getLocation(),lhs,rhs);}// ...}};这段 C 逻辑就是现代 AI 编译器前端如从 TorchScript 树到 MLIR的核心翻译逻辑。它像一台织布机将树状的抽象语法骨架源源不断地编织成 MLIR 高速公路上跑的高性能 SSA 数据流。总结如果说 MLIR 的底层的各种方言LLVM, NVVM是编译器伸向物理硬件的强壮触角那么 AST 就是编译器拥抱人类智慧的第一道视网膜。它成功将主观的代码文本提炼为客观的数学拓扑结构。只有深刻理解了 AST 是如何将高级语言的逻辑进行结构化收纳的你在后续手写 MLIR 前端转换器或设计高级算子方言时才能准确拿捏高级语义与底层指令之间的完美平衡。
)
