玻尔百科将人类可读的源代码转换为机器可执行指令的过程，通常被想象成一个单一、庞大的行为。然而，这种“黑箱”观点掩盖了现代编译器设计核心中优雅而模块化的现实。编译器的真正威力不在于一次巨大的飞跃，而在于一系列经过精心编排的、被称为“编译器遍”的微小转换。本文旨在揭开这一过程的神秘面纱，解答为何编译过程被构建成一条由专业化函数组成的流水线。在接下来的章节中，您将首先深入探讨支配这些遍的“原理与机制”，探索它们如何交互、相互依赖，并使用一种名为“中间表示”的共享语言。随后，“应用与跨学科联系”一章将揭示这一基本概念如何促成从强大的代码优化和现代语言特性，到安全和硬件管理领域的新颖应用等一切可能。
如果你问别人编译器是如何工作的，他们可能会想象一个单一、庞大的翻译行为——一个神奇的黑箱，吞噬人类可读的代码，然后吐出晦涩的机器语言。但是，自然界和优秀的工程学都很少青睐这种庞大的魔法。事实远比这优雅。现代编译器不是一次飞跃，而是一段沿着意义流水线前进的优美旅程。这条流水线上的每个工位都是一个编译器遍（compiler pass）：一个专门的函数，它接收程序，对其进行打磨、精炼，然后交给下一个工位。
让我们把每个遍想象成一个函数 ，它将我们程序的某种表示 转换为一个新的、略微更明确的表示 。那么，一个编译器就是这些函数的组合：。这种结构立即引发一个问题：为什么不只用一个庞大而复杂的遍呢？为什么要采用流水线？
答案在于任何单向过程的一个基本局限：你不知道接下来会发生什么。想象一下，你第一次读一本小说，在第 20 页，一个角色提到了一个直到第 300 页才解释的事件。你瞬间感到困惑。一个纯粹的“单遍”读者会卡住。他们无法在不了解未来的情况下理解这个引用。
编译器面临同样的问题。考虑一段在函数被定义之前就调用它的代码。一个单遍编译器从上到下读取代码，遇到这个调用时，它不知道这个函数是什么，期望什么参数，或者返回什么。它要么放弃，要么做出一个冒险的猜测。
这就是多遍（multi-pass）架构的力量所在。我们可以设计第一个遍，其唯一的工作就是当一个侦察兵。它不试图理解所有东西；它只是扫过整个程序，并建立一个“目录”——一个列出代码中任何地方定义的每个函数、变量和类型的清单。这张地图通常被称为符号表（symbol table）。然后，第二个遍可以开始真正的翻译工作。当它遇到同一个函数调用时，它现在可以在第一个遍提供的完整地图中查找它。困惑消失了。
这种关注点分离是编译器设计中一个反复出现的主题。通过将翻译这个艰巨的任务分解为一系列更小、更专注的遍，我们赋予了编译器一种全知的能力。它得以多次审视程序，每一次都获得更深的理解，就像我们重读一首复杂的诗以欣赏其层层含义一样。
这些遍并不直接操作你的源代码文本。在初始阶段之后，代码被转换成一种更结构化的形式，即中间表示（Intermediate Representation, IR）。IR 是编译器内部世界真正的母语，是所有后续遍都使用的通用语。它是一种精心设计的数据结构，使程序的逻辑、控制流和数据依赖关系变得明确。
在很长一段时间里，这个内部世界是完全隐藏的。编译器是一个真正的黑箱。但如今，许多最优秀的编译器都建立在透明的哲学之上。像 Clang/LLVM 这样的系统不仅允许，而且鼓励你窥视这个世界。它们可以在编译的任何阶段打印出 IR，让你观察你的代码在经过数十个、有时是数百个遍处理时如何变形和演化。你可以看到一个优雅的高级循环被转换为一堆低级的跳转和检查，然后看着一系列优化遍将这堆混乱重新雕塑成一个效率惊人的东西。
这种观察 IR 的能力带来了一个微妙但深刻的挑战。一个遍如何知道它与前一个遍讨论的是同一个东西？例如，一个优化遍可能会决定将名为 x 的变量重命名为 x_1 以避免冲突。另一个遍可能会制作一个函数的特化副本。如果下一个遍通过名称来识别事物，它就会迷失方向。它正在寻找的 x 不见了，而它想要分析的函数现在有了两个版本。
为了解决这个问题，编译器为程序中的每个实体——每个函数、每个变量——赋予一个稳定的语义身份（semantic identity）。这个身份不是基于其名称（名称是短暂的），而是基于某种不变的东西，比如它在原始源代码中的唯一位置，或者描述其声明上下文的规范路径。这就像给剧中的每个演员一个唯一的身份证号码。他们可以更换服装（名称），扮演多个角色（特化克隆），或者在舞台上移动（代码移动），但编译器总能通过他们不变的 ID 来追踪谁是谁。当程序的意义在流水线上穿行时，这个稳定的身份是将其维系在一起的线索。
当一系列遍准备好在一个定义良好的 IR 上操作时，它们应该按什么顺序运行？答案由逻辑决定。你必须先解析代码才能检查其类型。你必须先构建 IR 才能对其进行优化。这些依赖关系（dependencies）形成一个有向图，其中从遍 到遍 的一条边意味着 必须在 之前运行。编译器架构师的工作就是找到一个有效的序列——这个图的一个拓扑排序（topological sort）。
有时，这些依赖关系会创建一个严格、不可改变的序列。如果 需要 ， 需要 ，那么编译器就没有任何灵活性；它必须按 的顺序执行它们。但更多时候，依赖关系图包含分支，从而创造了选择的机会。例如，两个不同的分析遍可能都依赖于初始的 IR，但彼此之间没有依赖关系。它们可以按任意顺序运行，甚至可以并行运行。
我们可以使用图论中的概念完美地形式化这些关系。对于任何给定的遍，我们可以问：它的直接前置条件是什么？在编译器的语言中，这是它的直接支配节点（immediate dominator）——在通往它的每条路径上都保证已经运行的最后一个遍。同样，有些遍是不可避免的。无论编译器采取哪条优化路径，每一条最终都必须汇合并运行，例如，一个最终的代码生成遍。这样的遍是一个后支配节点（post-dominator）；它是所有路径在退出前必须流经的瓶颈。理解编译器的这张“路线图”对于高效地组织其工作至关重要。
为保证基本正确性所需的遍的排序通常是直接的。真正的复杂性和美感出现在优化领域。优化遍不仅转换代码；它们还为其他遍转换了可能性的版图。
考虑两种优化，我们称之为“冗余移除器”（如全局值编号，GVN）和“洞察调用者”（如去虚拟化，devirtualization）。
这创造了一个依赖循环：它们相互促成。正确的顺序是什么？没有唯一的正确顺序。解决方案是让它们共舞。一个复杂的编译器会运行一系列优化，然后……再运行一遍。冗余移除器运行，促成了洞察调用者。洞察调用者运行，又在下一次迭代中促成了冗余移除器。这个过程持续下去，各个遍互相帮助，直到达到一个无法再找到改进的平衡状态。这个最终的、完善的状态被称为不动点（fixed point）。
为了使这场舞蹈高效，编译器使用了一些更巧妙的技巧。它们认识到有些遍是幂等（idempotent）的：一旦它们运行过，再次对相同的代码运行它们不会产生任何进一步的变化（）。一个智能的流水线不会浪费时间重复运行已经完成其工作的幂等遍。此外，编译器不是在每次迭代时都从头重新分析整个程序，而是使用惰性、按需分析（lazy, on-demand analysis）。它们缓存分析结果，并且只对程序中被前一个遍实际更改的部分使缓存失效并重新计算信息。正是这种错综复杂、自我调节的遍之芭蕾，才使得现代编译器能够实现惊人的优化。
这给我们带来了一个最终的、令人费解的思考。编译器是一个程序，用某种编程语言编写。那么，像 C 或 Rust 这样的语言的第一个编译器是如何创建的？是什么编译了那个编译器？
答案是一个称为自举（bootstrapping）的过程。你从一个小的、可信的“种子”开始——也许是一个用更简单的语言编写的简单解释器，或者一个源代码足够小、可以手工验证的最小编译器。这个种子刚好足够强大，可以编译一个稍微复杂一点的编译器版本。然后，那个新版本被用来编译一个功能更丰富的版本。这个过程不断重复，编译器逐步构建出更强大的自身版本，直到完整的、带优化的编译器能够编译自己的源代码。
现代编程语言的整个大厦都建立在这条编译器遍链之上，它们被精心排序，以便通过自身的引导（bootstraps）将自己拉起来。这种有组织的转换序列不仅仅是构建其他程序的工具；它也是编译器自身存在的蓝图。于此，我们看到了这个概念的终极统一：将我们的思想转化为现实的逻辑，与允许编译器创造和完善自身的逻辑，是完全相同的。
在经历了编译器遍基本原理的旅程之后，你可能会将它们视为复杂机器中错综复杂的齿轮，是一系列旨在将人类可读的代码转化为计算机可执行内容而设计的转换。这确实如此，但这只是故事的开始。编译器遍的真正美妙之处不仅在于其机制，更在于其应用——这一系列自动化步骤如何促成了现代编程的诸多特性，释放了非凡的性能，甚至将计算的触角延伸至安全、硬件管理乃至物理学领域。正是在这些实际和意想不到的应用中，我们看到编译器遍不再仅仅是一个齿轮，而是一位大师级工匠的工具。
编译器的首要且最神圣的职责是生成一个正确的程序。有时，这项职责塑造了编译器的基本结构。考虑许多语言中的一个共同特性：在完全定义一个函数之前调用它的能力。想象两个函数，even 和 odd，它们互相调用以确定一个数的奇偶性。如果编译器严格地从上到下读取你的代码，它会在第一个调用处卡住，因为它还不知道另一个函数是什么。
解决方案是一个简单而深刻的多遍设计。编译器首先对整个文件进行一次快速的“侦察”遍。其唯一的工作是收集所有顶层声明——函数和全局变量的名称——并将它们的类型记录在一个主列表，即符号表中。只有在这张领土地图创建之后，第二个遍才开始详细分析函数体。现在，当它遇到一个在文件后面定义的函数的调用时，它只需在其符号表中查找名称，然后说：“啊，是的，我听说过这个！”这种两遍策略是一个基础性的应用，它使我们习以为常的自然而灵活的代码结构成为可能。
这种匠心工艺延伸到实现现代语言的优雅抽象。像“闭包”（closures）——捕获并携带其环境一部分的函数——这样的特性在处理器的裸机上并不存在。必须有一个编译器遍为这个概念注入生命。它通过执行一次转换来实现这一点：将闭包的高级思想转化为具体的数据结构，也许是一个包含函数代码地址和指向其捕获变量的指针的小对象。这个遍的具体设计涉及对性能有实际影响的权衡，决定了创建和使用这些强大编程结构的 时间和内存成本。编译器遍充当了从抽象编程范式到其物理实现之间的桥梁。
如果说正确性是编译器的职责，那么性能就是它的艺术。而这门艺术并非一蹴而就的天才之举，而是一场由优化遍管弦乐队演奏的交响曲。每个遍都是一位专家，以一种特定的方式改进代码，并常常为流水线中的下一个遍创造机会，以实现更伟大的功绩。
一个经典的例子优美地阐明了这种协同作用。想象一下，编译器遇到一段计算某个值的代码，但这个值仅在一个条件分支内部使用，而事后证明该分支永远不会被执行。
c := (2 - 2) != 0 这样的表达式，并立即将其简化为 c := false。if (false)，它知道 then 分支是不可达的，并将其从程序中完全剪除。里面的代码，包括对我们计算值的任何使用，都消失了。没有任何一个单独的遍能够实现这一点。常量折叠器为 CFG 简化器创造了机会，而后者又为死代码消除器创造了机会。这种连锁反应是现代优化流水线的精髓。
这一原则可扩展至最前沿的挑战。现代语言通常具有动态派发（dynamic dispatch）特性，其中像 shape.draw() 这样的调用可以调用圆形、方形或任何其他形状的 draw 方法。这种灵活性通常是有代价的——一个比直接调用慢的“间接调用”（indirect call）。为了解决这个问题，编译器采用强大的“全模块”遍，一次性分析整个代码库。如果这样的遍能够证明，在这个程序中，shape.draw() 只可能指向，比如说，Circle 和 Square 的实现，它就可以用一个快得多的直接检查来替换慢速的间接调用：if (shape is Circle) call Circle.draw() else call Square.draw()。这种被称为去虚拟化（devirtualization）的转换是编译器分析的一大胜利，它允许程序员使用优雅的抽象设计而无需支付全部性能代价。
编程语言的抽象世界与硅片的具体现实相去甚远。编译器遍构成了它们之间必不可少的桥梁，将高级意图转化为硬件特定且常常奇特的语言。
这一点在图形编程中表现得最为明显。现代图形管线涉及多个“着色器”（shader）程序——一个用于顶点（），一个用于片段（），等等。它们被编译为独立的模块，然后链接在一起。这个“管线链接”（pipeline linking）本身就是一个具有独特全局视野的编译器遍。它可以执行跨阶段优化，例如注意到顶点着色器中的一个复杂计算产生的结果，片段着色器实际上从未使用。链接器遍随后可以消除该计算和数据传输，节省宝贵的资源。
链接之后，后端遍接管工作，为特定 GPU 的架构量身定制代码。GPU 通常在一个“线程束”（warp）内以步调一致的方式执行数十个线程。传统的 if-else 分支，其中一些线程走一条路，另一些走另一条路，可能会效率低下。一个聪明的、依赖于机器的遍可以使用“谓词化”（predication）重写这个分支，即所有线程都执行两个分支的指令，但只有在谓词为真的线程中，结果才会被提交。这看似浪费，但它完美匹配了 GPU 的执行模型，并且可能比发散分支快得多。
这种以硬件为中心的优化在高性能计算中也至关重要。现代处理器具有 SIMD（单指令多数据）功能，允许单个指令同时对一整个数字向量执行操作。一个配备了强大向量化遍的编译器可以识别高级数据处理模式——比如在一个数组上映射一个函数、过滤结果并将它们归约为单个值——并将其转换为一个紧凑、高效的循环，利用这些 SIMD 指令。它将分离的概念步骤融合成一个硬件感知的操作，即时执行掩码计算和结果压缩，释放芯片的全部并行能力 [@problemid:3670078]。
几十年来，优化遍的主要目标是速度和代码大小。如今，编译器的职责已急剧扩展，人们正在开发新的遍来解决安全性、系统可靠性，甚至支配硬件的物理定律。
安全性： 现代软件面临持续威胁，而编译器正处于防御的前线。可以设计遍来强制执行安全策略。一个栈保护器（Stack Protector）遍在函数开始时在栈上插入一个“金丝雀值”（canary）——一个已知值——并在函数返回前检查它是否被覆盖，从而检测常见的缓冲区溢出攻击。另一个遍，控制流完整性（Control-Flow Integrity, CFI），会对间接调用进行插桩，以确保它们只跳转到有效的、预期的位置。其挑战是一个经典的遍调度问题：这些安全检查应该插入到复杂优化流水线的哪个位置？放得太早可能会抑制其他优化；放得太晚可能效率低下甚至不正确。因此，遍调度器必须在安全性和性能之间进行微妙的权衡，使其成为现代安全软件开发的关键组成部分。
运行时支持： 在像 Java 或 C# 这样的托管语言中，垃圾回收器（GC）会定期清理未使用的内存。为了安全地做到这一点，它必须能够在一个已知的状态下暂停所有应用程序线程——这个过程称为“stop-the-world”回收。但如果一个线程正处于一个非常长、紧凑的循环中怎么办？GC 可能需要等待一个无法接受的长时间。在这里，编译器与运行时系统合作。一个特殊的遍会在代码中插入安全点轮询（safepoint polls），尤其是在循环的“回边”上。这些轮询是微小、快速的检查，本质上是在问：“GC 是否要我暂停？”这确保了没有线程会运行太长时间而不提供一个干净的停止点，从而实现了低延迟的垃圾回收。这是一个编译器为整个运行时环境的健康和性能，而非为其自身逻辑来插桩程序的美妙例子。
物理管理： 也许最令人惊讶的应用是编译器作为热工程师的角色。处理器消耗的功率会转化为热量。如果一段代码的计算强度过高，它会产生一个热点（thermal hotspot），迫使芯片降低速度或冒着损坏的风险。基本关系很简单：温升与功耗成正比（）。一个热感知编译器遍（thermal-aware compiler pass）可以帮助管理这一点。通过分析不同指令的功耗特性，它可以识别出即将导致过热的循环。其反直觉的解决方案是什么？它策略性地在循环中插入空操作（No-Operation, NOP）指令——什么都不做的指令。每个 NOP 替换一个高功耗的浮点操作，降低了每秒平均功耗，从而降低了稳态温度。在这里，该遍的目标不是让代码更快，而是让它保持凉爽运行，这是编译器设计与热力学惊人的交集。
面对如此众多复杂且相互作用的遍，一个关键问题出现了：我们如何知道编译器本身是正确的？优化遍中的一个错误是最隐蔽的错误之一，它会悄无声息地破坏程序，同时看起来像是在改进它。对于交叉编译器（cross-compilers）来说尤其如此，它们在一个架构（如 x86）上运行，为另一个架构（如 ARM）生成代码。一个优化在宿主机器上可能完全有效，但在目标机器上却可能因为其内存模型、对齐规则或指令集的细微“怪癖”而中断。
构建可靠编译器的学科将遍的理论应用于其自身。一个严格的测试方法论涉及创建一个巨大的测试矩阵，系统地探索不同遍流水线、源代码模式和目标特定配置之间的相互作用。当检测到编译错误——即编译后的程序行为偏离了语言规范——时，寻找错误的追捕就开始了。工程师们不采用手动逐个禁用遍的方法，而是使用像 delta 调试（delta debugging）这样的自动化技术。这种算法尊重遍的依赖顺序，在遍子集的空间中进行有原则的搜索。它可以自动将一个由数百个遍组成的流水线中的故障，缩小到导致该错误的最小的一个或两个相互作用的遍。这就是编译器验证科学的实际应用，利用遍组织的逻辑本身来构建更稳健、更可信的工具。
从实现简单的语言特性到编排优化的交响曲，从架起通向裸机的桥梁到执行安全策略，甚至管理物理定律，编译器遍是一个具有非凡深度和实用性的概念。它是将编程艺术转化为计算现实的基本工作和创新单元。