第 15 章编译器流水线 on Go 语言原本

15.1 词法与文法

Mon, 01 Jan 0001 00:00:00 +0000

15.1 词法与文法

编译的第一站，是把源码文本变成结构化的抽象语法树（AST）。这要经过词法分析（把字符流切成 token）与语法分析（按文法把 token 组织成树）。3.2 鸟瞰过整条流水线，这一节专看它的前端，以及 Go 的文法为何被设计得如此「好解析」。

承担这两步的，是编译器里一个自成一体的包 cmd/compile/internal/syntax。它由两件器物构成： scanner（词法器）按字符读入、吐出 token 流；parser（语法器）以递归下降的方式消费 token、建出语法树。这个包的注释甚至自豪地写明，它的几个文件 scanner.go、source.go、 tokens.go 不依赖编译器其余部分，可单独编译成一个独立的库。词法与文法之所以能如此干净地切出来，根子在 Go 文法本身的简单。

15.1.1 为快速解析而设计的文法

Go 的文法是刻意为快速解析而设计的（1.1 的编译速度执念）。关键的一点是：它正则到足以被 LALR(1) 解析，因而无需复杂的回溯。早年的 gc 编译器正是用 yacc 喂一份 LALR(1) 文法（go.y）来解析 Go 的，这份文法的存在本身，就是「Go 文法可被单遍、确定地解析」的证据。换言之，解析一段 Go 代码，编译器读一遍 token 流、只看眼前一个 token 就能决定怎么走，不必回头重试，也不必在解析途中查询符号表。

这与 C/C++ 形成鲜明对比。C 的文法里，a * b; 究竟是「a 乘 b」还是「声明一个指向 a 类型的指针 b」，取决于 a 此刻是不是一个类型名，而这要查符号表才知道。解析与语义于是纠缠在一起，C++ 更因此背上了著名的 most vexing parse：Widget w(Thing()); 会被解析成函数声明而非对象构造。Go 的文法刻意回避了这类歧义，任何一段 token 的结构都由文法唯一确定，与名字的含义无关。解析器因此又快又简单，也不必把类型信息回灌给词法器。

15.2 中间表示

Mon, 01 Jan 0001 00:00:00 +0000

15.2 中间表示

15.1 把源码变成了语法树（AST）。AST 忠实记录了程序员写下的结构：变量、作用域、表达式的嵌套。可一旦要做优化，这套结构就显得太「高」了。考虑一句最不起眼的 x = x + 1：在 AST 里，左边的 x 与右边的 x 是同一个名字，编译器若想知道「这次用到的 x 究竟是哪一次赋值产生的值」，就得反复做作用域查找与数据流分析。名字会被覆盖，作用域会嵌套，赋值会把旧值冲掉，这些都让「一个值从哪来、到哪去」这件本该最基本的事变得晦暗。优化器最想要的，恰恰是把数据流摊在明面上。

于是 Go 编译器在 AST 与机器码之间，插入了一层专门为优化而生的中间表示（intermediate representation, IR）。它先把 AST 下降（lower）为一种更接近指令、却仍与具体机器无关的形式，再转换成本节的主角：静态单赋值形式（static single assignment, SSA）。SSA 是当代优化编译器近乎统一的中段表示，LLVM、HotSpot 的 C2、GCC 的 GIMPLE-SSA 都建在它之上。本节回答三个问题： SSA 是什么，为什么它让优化变得直接，以及 Go 的 SSA 流水线如何把一个函数从「与机器无关」一路打磨到「为某个架构生成的机器码」。

15.2.1 静态单赋值：每个变量只赋值一次

SSA 的定义只有一句话：程序中每个变量恰好被赋值一次。一旦某个名字被多次赋值，就给它编号，拆成多个互不相同的版本。回到 x = 1; x = x + 1，在 SSA 里它变成：

x_1 = 1
x_2 = x_1 + 1

两次对 x 的赋值成了 x_1 与 x_2 两个独立的、各自只被赋值一次的值。这一步看似只是机械改名，带来的好处却是结构性的：当后面某处用到 x_2，它的来源是唯一且显式的，就是上面那条 x_1 + 1，无需任何作用域查找或数据流推断。「定义」与「使用」之间于是连成一张明确的图（ use-def chain），值从哪来、被谁用，一望可知。常量传播、公共子表达式消除、死代码删除这些优化，本质上都是在这张图上做的局部改写，SSA 把它们从「需要全局分析」降格成了「照着图改」。

15.3 优化器

Mon, 01 Jan 0001 00:00:00 +0000

15.3 优化器

15.2 把前端的语法树降到了 SSA 这层中间表示，并说明了 SSA 的「每个变量只赋值一次」为何让优化遍写起来又准又快。这一节接着往下走：在这层表示上，编译器到底跑了哪些优化，又为什么偏偏是这几样。

读懂 Go 优化器，先要读懂它的取向。同样是把高级语言变成机器码，GCC 与 LLVM 愿意花上几秒甚至几十秒，把一个函数反复揉搓，换取最后那几个百分点的运行性能。Go 走的是另一条路：它只做性价比最高的那一批优化，把省下来的时间还给编译速度（1.1）。这不是能力不足，而是一道清醒的价值排序，本节最后会回到这条红线。我们先看 Go 愿意做的优化，再看 Go 1.21 引入的、把优化从「静态猜测」推向「数据驱动」的性能制导优化（PGO）。

15.3.1 内联：一切优化的入口

在 SSA 上做的诸多优化里，内联（inlining）地位特殊。它本身只做一件朴素的事：把一个小函数的函数体，直接展开到调用它的地方，省去一次函数调用的开销（建栈帧、传参、跳转、返回）。但它真正的价值不在省这点开销，而在于它为其他优化创造了条件。一次跨函数的调用，对优化器来说是一堵墙：墙那边的代码长什么样、参数是不是常量、返回值会不会被用到，它一概不知。内联把这堵墙拆掉，调用点两侧的代码合到一起，常量就能传播过去，分支就能被判定，死代码就能被消除。

举一个最常见的例子。sync.Once.Do 的快路径只是一次原子读，标准库把它写成一个独立的小方法：

func (o *Once) Do(f func()) {
    if atomic.LoadUint32(&o.done) == 0 {
        o.doSlow(f)
    }
}

如果不内联，每次 once.Do(f) 都要付一次调用开销，仅仅为了读一个字段。内联之后，atomic.LoadUint32 这一层包装也一并展开，整个快路径塌缩成几条指令，与手写一个内联的原子读没有区别。Go 标准库里大量「一层薄包装」的设计，正是建立在「编译器会把它内联掉」这个假设之上。想知道某个调用到底有没有被内联、为什么没有，可以用 go build -gcflags=-m，编译器会逐条打印它的内联决策（can inline、 inlining call to，或是 function too complex 这类拒绝理由）。

15.4 指针检查器

Mon, 01 Jan 0001 00:00:00 +0000

15.4 指针检查器

Go 是一门内存安全的语言。在常规代码里，类型系统保证每个指针都指向它声明类型的合法对象，垃圾回收（13）保证对象在仍被引用时不会被回收，运行时保证越界访问被挡在边界检查里。这套保证不是免费的，它建立在「编译器始终知道每个值的类型与布局」之上。可总有少数场景需要跳出这套体系：与 C 互操作（15.6）要按 C 的内存布局解释一段字节，对接操作系统的系统结构体要逐字节摆放，零拷贝地把 []byte 重解释成 string （5.1）要让两个类型共享同一段底层内存。Go 为这些场景留了一个逃生舱口：unsafe 包。

逃生舱口的代价是，一旦用它绕过类型系统，编译器与运行时原先提供的保证就部分失效，误用不再被语言挡住，而要靠程序员自己遵守一组并不直观的规则。这一节先讲清 unsafe.Pointer 的能力边界与规范列出的合法模式，再讲清其中最隐蔽的一类陷阱（uintptr 与垃圾回收的关系），最后讲编译器与运行时如何用「指针检查器」（checkptr）把这类潜伏的误用变成当场报错。

15.4.1 unsafe.Pointer：绕过类型系统的四条特权

普通指针 *T 之间不能随意转换，类型系统不允许把 *int 当作 *float64 来读写。unsafe.Pointer 是一种特殊指针，它在类型系统里开了一道口子，规范赋予它四条普通类型没有的特权：

任意类型的指针 *T 都可以转换为 unsafe.Pointer；
unsafe.Pointer 可以转换回任意类型的指针 *T；
uintptr 可以转换为 unsafe.Pointer；
unsafe.Pointer 可以转换为 uintptr。

前两条合起来，意味着借道 unsafe.Pointer 可以把任意 *T1 转成任意 *T2，从而以另一种类型解释同一段内存，这正是类型系统本想禁止的事。后两条让指针与整数互转，从而能对地址做算术。规范因此明确写道：Pointer 允许程序破坏类型系统、对任意内存读写，使用应格外小心。

1
2
3

// unsafe 包对 Pointer 的定义（ArbitraryType 仅用于文档，表示任意类型）
type ArbitraryType int
type Pointer *ArbitraryType

口子开得这么大，规范并不是说怎么用都行。它列出了若干「合法的转换模式」，承诺只有落在这些模式里的用法才有定义，偏离则是未定义行为。go vet 会检查代码是否落在这些模式内，没过 go vet 的 unsafe 代码不受任何保证。下面逐一过这些模式，它们覆盖了 unsafe 几乎全部的正当用途。

15.5 逃逸分析

Mon, 01 Jan 0001 00:00:00 +0000

15.5 逃逸分析

Go 程序员从不手动决定一个变量放栈还是放堆，这件事由编译器的逃逸分析（escape analysis）自动完成。它是 Go 性能的隐形功臣：把尽可能多的对象留在栈上，能大幅减轻垃圾回收（13 垃圾回收）的负担。这一节讲清它怎么判断、怎么实现、为何重要。

15.5.1 逃逸：决定栈还是堆

核心问题：一个变量该分配在栈上（随函数返回自动消失，零 GC 成本），还是堆上（生命周期不定，由 GC 管理）？判据是生命周期：若一个变量的引用在函数返回后仍可能被用到，它就不能放栈上（栈帧已随返回销毁），必须逃逸到堆。逃逸分析就是静态地回答这个问题，判断「这个变量的地址会不会跑出它所在函数的作用域」。

go/cmd/compile/internal/escape 把这件事说成两条必须维持的不变量：（1）指向栈对象的指针 不能被存入堆；（2）指向栈对象的指针不能活过该对象本身，比如声明它的函数已经返回、栈帧被销毁，或同一段栈空间在循环的不同迭代中被复用给了逻辑上不同的变量。只要一个变量的地址有可能违反这两条，它就被判定逃逸，改为堆分配。

最直接的观察手段是 go build -gcflags=-m，它让编译器把每一处逃逸判断打印出来。把下面这段喂给它（加 -l 关掉内联，让输出聚焦在逃逸本身）：

`1`	`func ret() *int { x := 42; return &x } // 返回局部变量的地址`

$ go build -gcflags='-m -l' demo.go
./demo.go:1:18: moved to heap: x

x 本是个普通局部变量，但它的地址被 return 带出了函数，调用方拿到的指针必须在 ret 返回后依然有效，于是 x 被「搬到堆上」（moved to heap）。这就是最典型的一类逃逸：return &x。

15.5.2 典型的逃逸场景

逃逸的根源只有一个：地址外泄到了一个活得比本函数久的地方。但它在代码里有几副不同的面孔，值得逐一认清。

15.6 cgo

Mon, 01 Jan 0001 00:00:00 +0000

15.6 cgo

「cgo is not Go.」这是 Rob Pike 在一篇博客里给 cgo 下的判词。它道破了一件容易被忽略的事：当你在 Go 源文件里 import "C"，写下一行 C.foo() 时，你已经踏出了 Go 这门语言为你划定的世界，进入了另一个由 C 的 ABI、C 的栈、C 的内存模型构成的世界。cgo 是这两个世界之间的桥，桥很有用，但过桥要付通行费，而且费用不低。

这一节不逐行翻译 runtime/cgocall.go，而是回答三个问题：为什么从 Go 调一个 C 函数会比调一个 Go 函数昂贵一两个数量级；运行时为这一次跨界究竟做了哪些事；以及由此衍生出的那条「Go 指针不可被 C 长期持有」的规则从何而来。读完它，「cgo is not Go」这句话的分量就具体了。

15.6.1 两个世界的落差

要理解 cgo 的代价，先要看清桥的两端有多么不同。Go 与 C 在四件根本的事情上各行其是。

调用约定不同。 Go 有自己的寄存器调用约定（2.2），参数与返回值的传递、栈帧的布局、哪些寄存器由调用方保存，都与 C 在该平台上的 ABI 不一致。跨界调用必须先把参数按 C 的 ABI 重新摆放，把栈指针对齐到 C 要求的边界。

栈不同。 Go 的 goroutine 栈是可增长的（14），初始只有几 KB，靠编译器在函数入口插入的栈检查在需要时拷贝、搬迁整条栈。C 函数对此一无所知，它假定自己跑在一条固定的、足够大的系统栈上，绝不会被搬走。让 C 代码跑在一条随时可能被移动的 goroutine 小栈上是灾难性的，因此跨界前必须切换到 M 的系统栈 g0，那是一条由操作系统分配、不会增长也不会搬迁的栈。

15.7 过去、现在与未来

Mon, 01 Jan 0001 00:00:00 +0000

15.7 过去、现在与未来

编译器是 Go 工具链里改动最频繁、却对用户最透明的部分。同一份源码一行不改，换一个新版本重新编译，往往就更快、更小、更优,你甚至不知道中间发生了什么。这一节把镜头拉远，回看编译器自身走过的路，再看它当下在做什么、接下来会往哪里走。贯穿始终的，是一条不变的价值排序:编译速度优先，生成代码质量其次，而两者都要在「可工程化」的前提下取舍 （1.1）。

值得先说清楚的是，本节谈的「变」全部发生在引擎盖之下。Go 对语言与工具的兼容性承诺，意味着这些重构不该惊动任何一行用户代码。下面要讲的两次大重写，正是在这个约束下完成的。

15.7.1 过去:从 C 到 Go，从 Plan 9 到 SSA

编译器自身经历了两次伤筋动骨的大变，方向却截然不同:一次换的是实现语言，一次换的是后端架构。

其一，实现语言:C → Go。 最早（到 Go 1.4 为止）的 gc 编译器是用 C 写的，沿用了 Plan 9 工具链的代码风格与构建方式。Go 1.5 完成了自举(bootstrap):编译器被机器翻译成 Go，从此是「用 Go 写的 Go 编译器」。这件事的细节见 3.3, 这里只强调它的意义。换语言不是为了赶时髦:C 版本无法利用 Go 自己的并发、内存安全与丰富的标准库，也无法让 Go 社区用熟悉的语言去读、去改编译器。自举之后，编译器才真正成为「社区可维护的 Go 程序」，这为后续一切重构铺平了路。代价是引入了一个自举链:要编译当前版本的 Go，先得有一个能跑的旧版本 Go，工具链因此需要小心维护这条向后的依赖。

顺带澄清一个常被混淆的命名:编译器叫 gc，是 “Go compiler” 的缩写，与垃圾回收（大写 GC， garbage collection）毫无关系。cmd/compile/README 开篇就专门提醒了这一点。

其二，后端架构:Plan 9 风格 → SSA。 自举只是换了笔，没换骨架。Go 1.5/1.6 的后端仍大体沿用 Plan 9 编译器的传统设计:基于一种较低层的指令表示直接做有限的优化与指派。这套后端能用，但难以承载现代优化,它的中间表示不便于做数据流分析，加一个新优化往往要在多处特判，扩展性差。

第 15 章 编译器流水线 on Go 语言原本

15.1 词法与文法

15.1 词法与文法

15.1.1 为快速解析而设计的文法

15.2 中间表示

15.2 中间表示

15.2.1 静态单赋值：每个变量只赋值一次

15.3 优化器

15.3 优化器

15.3.1 内联：一切优化的入口

15.4 指针检查器

15.4 指针检查器

15.4.1 unsafe.Pointer：绕过类型系统的四条特权

15.5 逃逸分析

15.5 逃逸分析

15.5.1 逃逸：决定栈还是堆

15.5.2 典型的逃逸场景

15.6 cgo

15.6 cgo

15.6.1 两个世界的落差

15.7 过去、现在与未来

15.7 过去、现在与未来

15.7.1 过去:从 C 到 Go，从 Plan 9 到 SSA

第 15 章编译器流水线 on Go 语言原本