1. 优化全貌编译器在后台做的事写 C 的人多多少少都听过“编译器优化”这五个字但真正把这五个字当成设计输入的人并不多。我对编译器优化的理解转折点来自于一次性能排查同一段数值计算只是把优化选项从 -O0 改成 -O2耗时从 8 毫秒降到 0.9 毫秒。那一刻我意识到运行的并不是我写的 C而是编译器根据我的 C 理解并重写后的机器码。从那以后我写代码时会把“编译器会怎么读这段代码”当成和“人怎么读这段代码”同等重要的事情。这篇文章不是教科书式的原理罗列而是我这些年用 GCC、Clang 这类主流编译器做性能优化时总结出来的实际策略。你可以把它当成一份地图先搞清楚编译器在哪个阶段做了什么再看我们可以通过什么手法把代码写得更容易被优化最后学会在优化失败时定位原因。适合刚想入门性能调优的 C 开发者也适合被某段代码性能搞到怀疑人生、想看看编译器到底干了什么的人。1.1 为什么 C 代码要依赖编译器优化C 的抽象层级一直往硬件常识靠拢但人和编译器看到的东西完全不同。人关注语义清晰、可维护、可扩展编译器关注指令序列、数据依赖、寄存器压力。如果一个程序运行慢问题通常不是 C 太抽象而是你的表达方式让编译器无法做出它本可以做的优化。C 标准给编译器留了极大的发挥空间只要不改变“可观察行为”允许它把代码改得面目全非。这就是所谓的 as-if 规则。它意味着编译器可以把两段逻辑等价的代码合并、删除、交换前提是对用户可见的输入输出结果一致。理解这个前提很重要它也是优化器最大的胆量来源。你在源码里看到的 if 分支、循环、临时变量在优化后的机器码里可能完全不存在。依赖编译器优化不是说可以乱写代码而是说要把精力花在“消除障碍”上。比如尽量让数据结构配得上访问模式、尽量让函数简单直接、尽量让边界条件清楚。编译器的能力并不是无限大它擅长在给定的约束里寻找代价最小的变换而我们的工作就是把这些约束松绑让它能走得更远。1.2 优化发生在哪三个阶段一条 C 代码从文本变成可执行的二进制要经过前端、中端、后端三个阶段。前端负责把源码解析成抽象语法树再生成中间表示中端在中间表示上做各种与目标机器无关的优化这里的优化最多也最关键后端把中间表示映射成具体 CPU 的汇编、寄存器分配和指令选择。阶段输入输出典型优化前端源码中间表示语法解析、语义分析、常量折叠中端中间表示优化后的中间表示内联、循环优化、死代码删除、向量化后端优化的中间表示目标机器码寄存器分配、指令调度、peephole 优化后端优化和 CPU 微架构关系紧密比如同样的循环在 Alder Lake 和旧款服务器 CPU 上指令调度策略就会不同。大多数时候我们关心的优化选项像 -O2、-O3控制的主要是中端和后端的优化强度。看代码优化效果时最好看汇编或者优化后的中间表示而不是试图从源码里推测最终结果。前端也会做一些基础优化比如直接在语法树阶段算出常量表达式的值。但真正产生质变的是中端的优化器。以静态单赋值形式为基础中端可以轻易地追踪一个值的来源、流向和存活范围进而执行各种变换。如果你想深入编译器优化理解 SSA 是绕不过去的底子。1.3 优化器的核心约束中端优化器并非所有变换都敢做。它受两个大约束标准定义的“可观察行为”和过程间的调用关系。可观察行为指程序对输入输出、文件、网络、可见的硬件交互等产生的效果。只要不改变这些行为编译器可以把一个循环删掉可以重新计算某个值可以把 A 函数插进 B 函数里。过程间调用关系则决定了内联、跨函数常量传播可行不可行。一个函数如果被很多文件调用修改它的签名很危险但通过链接时代码生成统一处理可以在最后阶段看到整个程序的调用图这时跨文件的内联和替换就变得可能。这也是为什么链接时优化正在成为大型 C 项目标配。我更想强调的一点是优化器是一个“规则推理器”不是人类。它不会被代码注释感动不会因为你用了一个合理的算法名就认为它是热路径。它只依据数据依赖、别名关系、调用代价模型做决定。所以写优化代码的第一条心法就是别祈求编译器理解你的意图把意图用 type、constexpr、显式分支概率告诉它。2. 编译器最常用的一批优化策略编译器优化策略非常多但底层逻辑是可枚举的。我挑几条在 C 日常代码中出现频次最高的来讲每一类都直接对应你可以在源码里看到的模式。2.1 常量折叠、常量传播与死代码删除这三者经常一起出现。常量折叠指在编译期直接算出常量表达式的值比如6 * 2直接变成 12常量传播指把一个已确定的常量值传给后续使用它的地方比如const int n 4; return n * n;里编译器会把n替换成 4死代码删除则是在某个计算完全没有意义时把它整体丢掉。constexpr int kMul 6; int scale(int x) { int tmp kMul * x; if (tmp 0) { return 0; } return tmp * 2; }这段代码如果用 -O2 编译输出的机器码大概率非常短。编译器会看到tmp 6 * x然后tmp 0分支等价于6 * x 0也就是x 0时返回 0而return tmp * 2等价于12 * x。因为x 0时表达式12 * x也是一定是 0所以整个分支可以合并成一句return x * 12。分支消失了临时变量没有了多余乘法也被消掉了。这类优化的价值被很多人低估。它不仅是快还能消除代码里的防御性分支让后续优化变得透明。反过来如果源码里使用了 volatile 变量、内联汇编等不可推理因素一下子就会打破传播链编译器只能保守地保留所有加载和分支。2.2 内联扩展最朴素的跨函数优化函数调用本身有成本参数传递、栈帧创建、返回地址保存、寄存器保存恢复。内联就是把被调用函数的体直接复制到调用位置省掉这些开销。但内联的好处远不止省调用开销更大的价值在于调用点原有的上下文信息可以继续向后传播。inline int max_value(int a, int b) { return a b ? a : b; } int compute_max() { return max_value(40, 20 10); }max_value被内联后编译器能看到a 40和b 30这两个常量于是整个调用变成return 40;。这种效果只有跨函数传播才能达到。类内部定义的小函数、模板实例化时生成的短小函数天然更适合内联。内联不是没有成本。它会复制代码函数一旦变大内联会导致指令缓存局部性变差反而慢。编译器会用启发式模型决定在哪些调用点内联也会通过属性帮她做决定比如__attribute__((always_inline))和__attribute__((noinline))。实际项目里我不建议大面积强制内联那不是优化是跟代价模型较劲。更好的做法是热路径上的纯逻辑尽量写进同一个编译单元让编译器的内联启发式有更完整的视野。2.3 循环优化展开、不变量提升和强度削减循环是为数不多的时间放大器。循环体每慢一点点会被迭代次数放大几万倍几十万倍所以几乎所有编译器都会特殊照顾循环。循环不变量提升是最容易理解的一条如果某次计算在循环体内不管迭代多少次结果都一样就把它移出循环。比如for (size_t i 0; i n; i) { count[i] factor * base; }factor * base和循环变量没有关系编译器会把它算到循环前面每次只存同一个结果。这里有个陷阱如果factor和base在循环内都不会被修改编译器很容易提升但如果它们可能是被其他函数修改的全局状态编译器为了不破坏可观察行为可能不敢提升于是你每次迭代都得重新做一次完全相同的乘法。循环展开则是把多个迭代合并成一个迭代的高级版本减少循环判断和跳转次数。像for (i 0; i n; i)这种常规循环编译器会自动拆成重复体四个八个一组前提是它知道 n 一定足够大且没有越界风险。强度削减指的是把代价高的操作替换成代价低的操作比如把循环里的乘法i * stride不断累加变成每次加法。这个优化在数组遍历、图像处理里很常见。你不需要手写这些变形但对一个真实的热循环知道编译器会做哪些变换能帮你判断瓶颈到底是算法本身还是表达方式卡了优化。2.4 向量化让硬件并行帮你算现代 CPU 有 SIMD 指令一条指令可以同时处理多个数据。编译器在满足特定条件时会把普通循环编译成用 SIMD 指令执行的向量化循环。最典型的例子是数组求和float sum_array(const float* data, size_t len) { float result 0.0f; for (size_t i 0; i len; i) { result data[i]; } return result; }在 -O3 下如果编译器能证明data指向的内存不会和result有别名关系并且循环长度是安全的它就能用向量累加同时处理四到八个元素。这里最大的障碍是浮点运算的严格舍入规则编译器默认必须保证结果和源码逐次累加的舍入完全一致而向量化会改变求和顺序。很多编译器因此不会在默认浮点模型下自动向量化或者只能在极特殊情况下向量化。为了突破这个约束有些项目会显式打开非严格浮点模型或者手写 SIMD 原语。我更倾向于另一种思路把数据类型换成和舍入无关的整数或者针对特定问题使用定点表示如果确实需要浮点再用-ffast-math承受其风险。3. 帮助编译器优化代码的工程手法了解编译器擅长什么之后真正的门槛在于把日常工作写成“编译器友好”的形式。这一节讲的主要是构建参数和代码风格层面的实践。3.1 优化级别不是越高越好C 项目的优化级别选择其实是一种策略平衡。我见过的团队有的默认 -O2有的为了调试用 -Og有的追求吞吐用 -O3。常用级别大致是这样的级别定位适用场景注意事项-O0最保守便于调试开发调试、崩溃定位变量基本可见但速度极慢-O1局部优化为主需要较快编译、要保留性能大概可用不适合最终 benchmark-O2日常推荐兼顾性能与代码大小绝大多数线上程序不会做自动向量化也别指望浮点重排-O3深度优化倾向向量化、循环变换计算密集场景编译变慢代码膨胀个别场景反而更慢-Os以代码体积为目标嵌入式、包体积敏感在 -O2 基础上压缩体积-Og为调试设计的优化级别需要调试信息又不想性能惨不忍睹优化程度低但比 -O0 快我有个习惯发布前必用 profile 数据引导优化而不是上来就开 -O3。因为 -O3 默认会把一些代码展开导致指令缓存压力增大某些对分支预测敏感的代码反而会变慢。如果评估下来 -O3 没有明显收益不要强制用不是所有代码都吃这套。真正决定吞吐的往往是数据结构局部性、分配频率和算法复杂度。3.2 写代码时给编译器留线索源码层面的细节比很多开发者以为的更有决定性。我列几个高频场景。第一多用 constexpr 和 const。常量表达式不仅能在编译期求值还能让后续优化消除调用链。比如把只依赖参数的小函数标成constexpr编译器有很大概率把常量入参的调用直接算掉。第二把指针别名的空间打开。C 默认允许两个不同类型的指针可能指向同一块内存编译器在优化时只能做保守假设。以普通引用方式传参时如果函数内部要写一个指针而读操作又在同一个循环里编译器没办法证明不会自己写自己读的值。很多看起来应该快起来的循环就是因为别名问题被限制住。第三循环上界要尽量明确。编译器需要能证明循环一定会结束且访问不会越界才能做展开和向量化。使用size_t比 有符号整型处理溢出时要少一些麻烦把限制条件改成i n n 0这种直接形式编译器更容易推导出上界。第四重视分支概率提示。比如 C20 的[[likely]]和[[unlikely]]可以明确告诉编译器哪个分支更常见让后端把热分支布局在跳转更顺的位置。不过别滥用如果你把所有分支都加上编译器就失去了判断依据。3.3 链接时优化和档案引导优化单个翻译单元内的优化有天然瓶颈编译器看不到其他文件里发生的事。你在这个文件里定义函数调用在另一个文件如果不做整个程序范围的分析它就无法跨文件内联或调整调用格式。链接时优化的作用就是打破这个桶子。GCC 和 Clang 提供-flto选项在链接阶段重新读取各编译单元产生的中间表示进行跨文件优化。代价是链接时间变长内存占用变大。对大型项目来说收益往往明显但需要配合好构建缓存和增量编译机制。档案引导优化是另一类系统性手段。它先让程序跑一遍代表性业务记录下哪些分支更热、哪些循环更容易满足展开条件第二次编译时编译器根据这些档案信息做路径优化。我的经验是两个步骤先用-fprofile-generate编译跑代表性负载再用-fprofile-use编译。这两个选项在 GCC、Clang 里都有对应实现但注意生产环境的负载一定要贴合真实流量否则引导数据反而会把优化带偏。4. 我踩过的优化失效现场优化没有发生时大部分人第一反应是加优化选项但真正原因往往藏在代码结构和语义细节里。下面几个场景是我在不同阶段真实踩过的每个都有典型性。4.1 别名吞噬了所有优化有一次处理一个图像缩放模块瓶颈是一个内层像素循环。代码看起来非常简单void copy_pixels(const float* src, float* dst, size_t n) { for (size_t i 0; i n; i) { dst[i] src[i] src[i stride - 1]; } }我检查汇编后发现每次迭代都做了两个独立的加载向量化和重排都没发生。后来查源码才意识到dst和src在函数外部可能是同一个数组的不同偏移编译器不能假定写入dst不影响下次读src于是每次写dst[i]都必须等前面的读完成。解决办法很简单在需要的地方显式告诉编译器这两个指针不重合。在 C 里可以用新标准里的std::assume_aligned或者编译器扩展__restrict明确标注。从此之后我对跨函数的指针参数总是先问一句“编译器能确认这两个内存区域没有交集吗”4.2 浮点严格语义挡住向量化求和循环不向量化这事我碰到过好几次。源代码是减少运算但默认浮点模型要求每次加法按源码顺序舍入编译器自然不敢把它拆成四个并行通电序列再组合。严格来说这不一定算 Bug而是标准定义下的一种“安全”行为。解决方式有三种接受现状打开非严格浮点模型比如-ffast-math或者把需要并行累加的部分拆成多个累加器最后合并。第三种方案不需要改变编译参数但要求你对浮点精度取舍有把握因为并行累加的顺序变化会改变最终舍入结果。4.3 内联和代码膨胀的取舍过度内联也是优化失败的一种。我写过一个小工具函数因为被标成了always_inline被复制到十个调用点结果二进制体积陡增热循环的执行体也不在指令缓存里了反而比不内联时慢。编译器不是不用内联而是在“减少调用开销”和“增加代码体积”之间找平衡。正确做法是让函数定义和调用点在同一个编译单元然后用 profile 数据告诉编译器哪条路径是热的。对于一些只被调用一两次、逻辑本身又只有一两行的函数我可以理解你手痒想标 automatically inline但函数体一旦超过二十行或者所在的调用点冷热差异极大内联就不应该靠强行指令维持应该把决策权交还给优化器。偶尔的例外是回调函数或临界区里的短函数配合[[likely]]让编译器有足够参考。4.4 调试时的变量丢失问题优化太强会带来一个著名的副作用调试器里看不到局部变量。因为编译器为了性能把一个变量直接写进常量或寄存器没在栈上给保留一个“可读”的副本。很多开发者在出问题时把优化级别降到 -O0问题立刻消失然后给出“开优化就 Bug”的结论。我的应对是使用-Og。这个级别专为调试场景设计既能保留一部分优化又尽量维持变量与源码行号的可观察性。但也别把 -Og 当优化性能测量等级它保的是“可调试”而不是“最快”。真正需要排查优化相关问题时我甚至会同时看 -O0 和 -O3 两份汇编对比出哪一次变换把状态从栈搬去了寄存器和常量。5. 怎么确认优化确实发生没有汇编视图的优化讨论很容易变成玄学。这一章我讲几个可以直接上手的观察手段以及我自己的操作记录。5.1 三条编译命令我通常会根据目的选择其中一条c -O2 -S source.cpp -o source.s这条生成汇编适合看最终机器指令布局。c -O2 -fdump-tree-optimized source.cpp -o /dev/null这条把中端优化后的中间表示倒出来适合看内联、常量传播、循环变换是否执行。clang -O2 -S -emit-llvm source.cpp -o source.ll这条生成 LLVM IR适合在做跨文件优化前快速确认 IR 层面的数据依赖关系。我从来不会只看一行汇编就下结论。一次循环是否向量化我会去找 vaddps 或者 vfmadd 这类 SIMD 指令一次函数是否内联我会看目标函数的 label 是否出现在调用点附近。代码一多就把这些片段相互对照才能看出优化器的整体判断。5.2 案例分析一段求和代码的观察记录我拿最普通的求和函数做过实验。源代码是这样size_t sum_array(const int* data, size_t n) { size_t sum 0; for (size_t i 0; i n; i) { sum data[i]; } return sum; }用 -O2 编译我只看到普通的循环累加指令加载一个 int加到寄存器自增计数器比较跳转。这就是正常的标量循环。改用 -O3 后汇编里出现了一段预处理逻辑先用目标机器向量宽度把前 16 个元素批量加载并累加剩下不足 16 个的陈年尾巴再逐元素处理。循环展开发生了树的重复体出现了 4 次。这里编译器能够放心展开的前提是它知道data指向的内容不可被本轮循环内修改且 n 对边界条件有充足证明。一切都在 IR 里可追溯。但你再把这个函数放在一个更大的工程里如果sum_array的定义在另一个编译单元且调用点把data和n都从外部传入LTO 不打开时内联可能不成立跨文件常量传播也不可能。速度裁剪之后程序整体效率取决于链接阶段能不能继续深入。这就是为什么一个大项目要对 LTO 和 PGO 综合考虑而不是只盯着单个小函数。5.3 看汇编时该看什么如果初次打开汇编很容易被密密麻麻的指令劝退。我建议先有目的地搜几个关键词call指令出现次数如果函数调用本身是开销你会看到很多call看目标地址是不是被直接调用。直接调用意味着就可能被内联成相对跳转而间接调用会带来更大的开销。SIMD 指令特征x86 的vaddps、vpmulld、vmovdquARM 的vaddq。看到这些一般说明向量化成功。分支指令数量循环展开后分支判断会从每迭代一次变成每几次迭代一次分支少了不代表循环简单了但通常说明编译器加大步长。注释标签GCC 和 Clang 的汇编输出里会带源码文件名和行号可以辅助定位当前指令对应哪一行 C。大多数时候我并不是要把汇编全部读懂而是要看“优化器有没有按照我认为的方式做变换”。看到意外结果再去查是不是别名、浮点模型、未定义行为等问题挡住了解锁。这个过程反复几次之后你对开哪些优化项、怎么写代码开始有非常强的直觉。6. 长期有效的一些心得体会优化是一个不断验证、排除和微调的过程单独一个技巧能解决的问题其实有限。写到这里我想分享几条长期沉淀下来的原则。6.1 让编译器看见完整信息编译器优化和信息缺失是死敌。你写的代码如果抽象层次太高类型信息够多编译器都知道得更早就能更早展开死代码并传播常量。反过来过早把逻辑拆到单独的动态库里或者通过函数指针、虚函数调用热点路径优化就很难穿透这种边界。不是让你放弃抽象而是让“热路径”上的抽象扁平化、透明化。除非是虚函数设计符合业务需要否则别用一个虚调用保护一个两行熟杀的纯逻辑。6.2 性能剖析先于优化猜测我见过最多无效优化的场景是没有 profile 直接对着源码猜热点。编译器再厉害也不能凭空提高某个被错误假设为热点的代码效率。正确顺序应该是先测量找到真正瓶颈再看汇编判断优化是否到位最后改代码或者改编译策略。如果修改后性能没有显著变化问题往往出在错误的瓶颈判断而不是编译器没有执行某种变换。6.3 把优化后的代码可读性当回事优化不是跟可读性对立的。我的原则是功能代码保持自然、边界清楚、常量显式只在经过测量证明某个函数是热点时才引入循环展开、手动向量化等复杂度较高的表达。而且我会把优化意图注释在代码里让后来的人知道为什么这段不如常规写法直观。很多项目的高性能代码难以维护不是因为优化太深而是因为注释没有说明每种变换向编译器传递了什么信号。记录这一点能避免半年后同事和你自己都看不懂当初为什么这么写。我对编译器优化的核心态度不是“编译器越聪明我就越可以随意”。编译器确实很强但它的强项更接近于“在大量小决策中寻找局部最优”而不是“推翻你设计上违背数据局部性的整体选择”。搞清楚它如何看代码、如何变换代码、在什么条件下会停手才是把 C 性能潜力榨出来的正路。