2015 年，Anton Ertl 在一篇题为《What Every Compiler Writer Should Know About Programmers》的论文中，向编译器开发者发出了一个直白的警示：基于未定义行为（Undefined Behavior, UB）的 “优化” 往往弊大于利，真正的性能提升应来自对程序员实际行为模式的理解与尊重。近十年过去，随着编译器愈发激进，这一洞察不仅没有过时，反而在 AI 驱动代码生成、大规模系统调试等场景下显得更为关键。本文将以 Ertl 的论文为核心，结合现代编译器设计实践，梳理编译器作者应如何从错误消息、优化启发式与调试支持三个维度，构建更符合开发者直觉的工具链。
程序员行为模式：编译器设计的盲区
程序员并非遵循形式语义的理性主体，而是一系列习惯、直觉与试错经验的集合。Ertl 在论文中指出，程序员常会写出依赖特定编译器实现细节的代码，即便这些代码触发了未定义行为。更关键的是，他们往往对 UB 的后果缺乏清晰认知，误将某种编译器的特定输出视为语言标准行为。这种认知偏差使得基于 UB 的激进优化成为一颗定时炸弹：编译器可能 “合法” 地生成与程序员预期截然不同的代码，导致性能下降甚至逻辑错误。Ertl 通过实测数据表明，这类优化带来的速度提升通常仅在 1.05 倍减速到 1.04 倍加速之间，微乎其微，却引入了巨大的维护与调试成本。
因此，编译器作者的第一课是：优化不应以破坏程序员心智模型为代价。真正的优化（如内联、常量传播、循环不变量外提）与源码级优化是正交的，它们提升性能而不改变程序的可观测行为。相反，那些依赖 “程序不会触发 UB” 假设的优化，往往只是编译器作者的一厢情愿，忽视了程序员在现实世界中的编码习惯。
启示一：错误消息 —— 从 “语法错误” 到 “诊断对话”
当程序员看到一段错误消息时，他们正在执行一次快速的因果推理：哪里错了？为什么？我该怎么改？传统的编译器错误消息常常失败于此，它们堆砌内部术语（如 “非终结符”、“LR 状态”）、指向模糊的代码范围，或给出 “SYNTAX ERROR” 这类毫无帮助的提示。
现代编译器设计强调错误消息应匹配程序员的直觉流程。一个好的错误消息应遵循四层结构：问题类型（如 “类型错误”）、具体位置（文件：行: 列，辅以光标指示）、原因解释（用程序员熟悉的语言概念表述），以及修复建议（简洁的提示，可扩展为详细帮助）。例如，与其输出 “invalid operands to binary +”，不如说 “不能将 ‘string’ 类型与 ‘int’ 类型相加”，并指出相应的变量声明位置。
Ertl 的观察与此呼应：程序员在调试时，本质是在模拟编译器的解析与类型检查过程。因此，错误消息应当融入这个模拟过程，解释 “编译器在此处期待什么，但遇到了什么”。这种设计不仅能加速调试，还能在教育层面帮助程序员建立更准确的语言模型。
启示二：优化启发式 —— 在激进与保守间寻找平衡
优化启发式是编译器性能的核心，但也最易与程序员预期冲突。Ertl 论文的核心论点是，许多号称提升性能的 UB 相关优化，实际收益甚微，却迫使程序员要么禁用优化（牺牲真正有益的优化），要么投入大量精力进行代码 “净化”（sanitizing），这永久增加了维护成本。例如，某些高性能解释器使用的 “线程代码” 技术，在标准 C 中属于未定义行为，若强行用 sanitizer 工具约束，可能导致性能下降数倍。
因此，编译器作者应重新评估优化启发式的优先级：
- 区分 “有益优化” 与 “UB 优化”：将优化通道分类，允许用户选择性启用那些不依赖 UB 的优化（如
-O2不含激进 UB 优化），而将基于 UB 的优化置于独立标志（如-fstrict-aliasing、-fno-strict-overflow）下，并明确告知其风险。 - 采纳 “常见模式优先” 原则：分析大规模代码库中程序员的常见习惯，例如特定的循环结构、内存访问模式，并确保优化器在这些模式上表现良好，而不是针对极端边缘案例进行优化。
- 提供优化反馈：在输出中简要说明执行了哪些关键优化，尤其是那些可能改变代码行为的优化，帮助程序员建立因果关联。
启示三：调试支持 —— 让优化后的世界可见
优化往往使调试变得困难，因为生成的机器码与源代码之间的映射变得复杂。程序员在调试优化版本时，常遇到变量值 “不可用”、单步执行行为诡异等问题。Ertl 指出，当优化基于 UB 时，问题会更严重：调试器可能显示完全无关的值，因为编译器已假设某些路径不会执行。
强化调试支持意味着：
- 保持调试信息的一致性：即使进行了激进优化，也应尽可能保留变量位置、行号映射等调试信息。DWARF 等标准已支持许多高级功能，编译器应充分利用。
- 集成 sanitizer 作为可选项而非负担：AddressSanitizer、UndefinedBehaviorSanitizer 等工具对于发现 UB 至关重要，但编译器作者应努力降低其运行时开销，并提供分级检测级别，让程序员能在开发阶段以可接受的成本使用。
- 提供 “优化视图” 工具：开发辅助工具，允许程序员查看优化前后的代码对比，理解特定优化如何转换了他们的代码，这尤其有助于教育程序员编写优化友好的代码。
可落地参数与清单
基于以上分析，以下是一份面向编译器作者的可操作清单：
错误消息设计
- 清晰度阈值：主错误消息不超过 1 句，长度 ≤ 120 字符。
- 定位精度：错误指示应聚焦于 ≤ 3 个 token 的范围，避免高亮多行。
- 术语一致性：建立内部术语到用户术语的映射表（如 “非终结符” → “函数参数列表”）。
- 帮助层级：默认显示核心消息与位置，通过
-fdiagnostics-show-option或 GUI 按钮提供扩展解释与示例。
优化启发式调整
- UB 优化隔离：将依赖严格别名、有符号溢出等 UB 的优化移至独立标志，默认不启用。
- 收益监控：为每个优化通道添加性能贡献统计，定期评估其在实际代码库上的平均加速比与回归率。
- 模式检测：在测试套件中加入从热门开源项目提取的常见代码模式，确保优化器对其处理良好。
调试支持增强
- 调试信息保留率：设定目标，在
-O2下保留 ≥ 85% 的变量位置信息。 - Sanitizer 开销目标：力争 AddressSanitizer 的内存开销控制在 2 倍以内，运行时开销在 1.5 倍以内。
- 工具链集成：提供
-fopt-view标志，生成 HTML 报告展示关键优化决策点。
结语
编译器不仅是将高级语言翻译为机器码的工具，更是程序员与计算机之间最重要的中介。Anton Ertl 在 2015 年的论文提醒我们，这个中介的设计必须建立在对程序员真实行为的深刻理解之上，而非纯粹的形式逻辑。通过将设计重心从 “基于规范的优化” 转向 “基于实践的辅助”，编译器作者可以打造出更加强大、可靠且易于使用的工具，最终赋能整个软件生态系统。正如 Ertl 所观察到的，真正的进步来自于编译器与程序员的协作，而非对抗。
资料来源
- Anton Ertl. "What Every Compiler Writer Should Know About Programmers, or 'Optimization' Based on Undefined Behaviour Hurts Performance". KPS 2015.
- 编译器错误消息设计最佳实践综述（基于多篇学术文献与行业指南）。