1. 这不是“编译器黑箱”，而是你每天写的代码在CPU上真正跑之前，被悄悄重写过多少遍
“编译原理（十六）——中间代码优化（1）”这个标题，乍看像教科书目录里一个不起眼的章节编号，但如果你写过C/C++、用过GCC或Clang编译项目，甚至只是在IDE里点下“Build”后盯着进度条等几秒——那这几秒里，中间代码优化就是那个最沉默、最勤快、也最容易被忽略的幕后工程师。它不生成最终的机器指令，也不做语法检查，但它会把你的for (int i = 0; i < n; i++) { sum += a[i] * b[i]; }，悄悄变成三重循环展开+向量化加载+寄存器复用的紧凑指令流；也会把一段看似无害的if (x > 0 && y > 0) { ... }，在未执行前就判定出x永远为负，直接删掉整个分支。这不是魔法，是编译器在IR（Intermediate Representation，中间表示）这一层，对程序逻辑进行的系统性“外科手术”。
我带过几个编译原理实践课，发现初学者常有两个典型误区：一是以为“优化=加-O2参数就完事”，二是把优化当成“越快越好”的模糊目标。其实完全相反——优化必须建立在精确的语义保持基础上，任何改动都不能改变程序的可观察行为（比如输出、IO、内存可见性）。它更像一位极其谨慎的律师，每改一行IR，都要反复核验：变量生命周期是否仍合规？指针别名关系是否被破坏？异常路径是否仍能正确回滚？这些约束，恰恰是它比前端词法/语法分析、后端指令选择更难啃的原因：它既要懂程序的“意思”，又要懂硬件的“脾气”。
这篇文章聚焦于中间代码优化的第一阶段——结构化IR上的局部与全局优化，不涉及LLVM IR或SSA形式化推导，而是从一个真实函数片段出发，手把手拆解GCC和LLVM在-O1级别默认启用的几类核心优化如何逐层作用。你会看到：为什么a = b + c; d = a * 2;会被合并成d = (b + c) * 2；为什么一个空的for(;;);循环在Release模式下会彻底消失；为什么调试版里能断点的变量，在优化后突然“找不到”。这些不是编译器bug，而是优化在语义安全边界内做出的必然选择。适合正在学编译原理的学生、想深入理解性能瓶颈的C/C++开发者，以及所有好奇“我的代码到底被编译器怎么对待”的人。
2. 中间代码优化的本质：在语义不变前提下，让IR更贴近硬件执行效率
2.1 为什么非得先转成中间代码？直接从源码生成汇编不行吗？
这个问题我当年在某高校实验室调试一个实时音频处理模块时问过导师。当时我们用C写了一个FFT核心，Debug版运行正常，但一开-O2就出现音频爆音。导师没急着看汇编，而是让我用clang -emit-llvm -S导出LLVM IR，结果一眼就发现：优化器把循环计数器i的符号类型从signed int悄悄提升为unsigned int，而我们的算法依赖i在溢出时变为负数来触发退出条件——这违反了C标准中“有符号整数溢出是未定义行为（UB）”的规定，编译器因此认为i永远不会溢出，把循环判定逻辑整个删掉了。
这就是中间代码存在的根本原因：源码（Source Code）是给人读的，汇编（Assembly）是给机器跑的，而中间代码（IR）是给编译器“思考”的。它剥离了语言语法糖（如C的++、Python的for in），统一成极简的三地址码（Three-Address Code, TAC）或SSA形式，让优化规则可以跨语言复用。比如GCC的GIMPLE、LLVM的LLVM IR、Java JIT的HIR，底层都遵循类似逻辑：每个指令最多一个运算符、两个操作数、一个结果。像x = a * b + c会被拆成：
t1 = a * b x = t1 + c这种结构让“公共子表达式消除（CSE）”、“死代码删除（DCE）”等优化能通过简单的图遍历实现——如果t1只被x使用，且x后续不再被读取，那t1这行就是死代码；如果另一处也有a * b，就可以复用t1。这种确定性，是直接在AST（抽象语法树）上做优化无法保证的。
提示：不要混淆“中间代码”和“字节码”。Java class文件或Python .pyc是为虚拟机设计的可执行中间格式，而编译器IR是纯内部数据结构，不暴露给用户，也不保证跨版本兼容。它的唯一使命是让优化过程可证明、可复现。
2.2 优化的铁律：语义等价性（Semantic Equivalence）是不可逾越的红线
所有优化技术都绕不开一个数学定义：对于任意输入I，优化前IR执行结果R_old(I)与优化后IR执行结果R_new(I)，必须满足R_old(I) ≡ R_new(I)。这里的“≡”不是简单值相等，而是可观察行为一致。具体包括：
- 程序输出：
printf、write()等系统调用的参数和顺序不能变； - 内存副作用：对volatile变量的读写次数、顺序必须保留；
- 控制流可观测性：
setjmp/longjmp的跳转点、异常处理路径不能被合并或删除； - 未定义行为的“不保证”：如前面提到的有符号溢出，优化器有权假设它不发生，但这不叫“改变语义”，因为原程序本就处于未定义状态。
我曾参与一个嵌入式固件项目，客户要求关闭所有优化以确保时序可预测。我们照做了，但发现某个ADC采样中断服务程序（ISR）在-O0下偶尔丢点。用逻辑分析仪抓波形才发现：未优化的IR里，编译器为每个局部变量分配了独立栈空间，导致ISR入口压栈操作耗时波动；而-O2启用的“寄存器分配优化”把频繁访问的采样计数器全程放在r4寄存器，消除了栈访问抖动。这里的关键是：优化没有改变ADC触发逻辑、采样值读取顺序、DMA缓冲区管理——所有可观察行为100%一致，只是把“不可观测的实现细节”（栈访问）换成了更稳的寄存器访问。这才是语义等价的正向案例。
2.3 优化层级金字塔：从局部到全局，从简单到复杂
中间代码优化不是一锅炖，而是分层推进的精密流水线。按作用域和复杂度，可划分为四个层级：
| 层级 | 作用域 | 典型技术 | 执行时机 | 实例 |
|---|---|---|---|---|
| 局部优化 | 单个基本块（Basic Block）内 | 常量折叠、代数化简、无用赋值删除 | 前端后、中端前 | x = 3 + 4;→x = 7; |
| 循环优化 | 单个循环结构内 | 循环不变量外提、归纳变量强度削弱、循环展开 | 中端核心 | for(i=0;i<10;i++) a[i]=i*2;→a[0]=0;a[1]=2;...a[9]=18; |
| 全局优化 | 跨基本块（同一函数） | 全局公共子表达式消除、活跃变量分析、死代码删除 | 中端主干 | if(cond) x=5; else x=5;→x=5; |
| 过程间优化 | 跨函数调用 | 内联展开、过程间常量传播、跨函数死代码删除 | 中端后期或链接时 | func(x) { return x+1; }被调用处y=func(3);→y=4; |
注意：层级越高，收益潜力越大，但分析成本也指数级上升。现代编译器（如GCC 12+、Clang 15+）默认在-O1开启全部局部+循环+全局优化，但过程间优化需显式加-flto（Link Time Optimization）。这也是为什么很多项目在升级编译器后，即使不改代码，性能也能提升10%-15%——新版本在相同层级做了更激进的等价变换。
3. 核心优化技术实操解析：从IR生成到效果验证
3.1 准备工作：用真实代码生成可读IR，建立直观认知
别被“IR”吓住，它本质就是编译器内部的“汇编草稿”。我们用一个经典例子切入：计算数组点积的函数。
// dotprod.c int dotprod(int *a, int *b, int n) { int sum = 0; for (int i = 0; i < n; i++) { sum += a[i] * b[i]; } return sum; }用Clang生成人类可读的LLVM IR：
clang -O1 -S -emit-llvm dotprod.c -o dotprod.ll打开dotprod.ll，关键部分如下（已简化注释）：
define dso_local i32 @dotprod(i32* %a, i32* %b, i32 %n) #0 { entry: %cmp = icmp slt i32 0, %n ; 比较 0 < n br i1 %cmp, label %for.body, label %for.end ; 若假，跳过循环 for.body: ; 循环体入口 %i.0 = phi i32 [ 0, %entry ], [ %inc, %for.body ] ; PHI节点：i的当前值 %sum.0 = phi i32 [ 0, %entry ], [ %add, %for.body ] ; PHI节点：sum的当前值 %arrayidx = getelementptr inbounds i32, i32* %a, i32 %i.0 ; a[i]地址 %load = load i32, i32* %arrayidx, align 4 ; 加载a[i] %arrayidx1 = getelementptr inbounds i32, i32* %b, i32 %i.0 ; b[i]地址 %load2 = load i32, i32* %arrayidx1, align 4 ; 加载b[i] %mul = mul nsw i32 %load, %load2 ; a[i]*b[i]，nsw表示无符号溢出 %add = add nsw i32 %sum.0, %mul ; sum += ... %inc = add nsw i32 %i.0, 1 ; i++ %exitcond = icmp slt i32 %inc, %n ; i+1 < n ? br i1 %exitcond, label %for.body, label %for.end ; 继续或退出 for.end: %sum.1 = phi i32 [ %sum.0, %entry ], [ %add, %for.body ] ; 循环后sum的值 ret i32 %sum.1 }看到没？原始C代码的for循环，在IR里被拆解成：
- 入口比较：
icmp slt i32 0, %n判定是否进入循环； - PHI节点：
%i.0 = phi i32 [ 0, %entry ], [ %inc, %for.body ]表示i在不同控制流路径下的值（entry路径为0，循环体路径为%inc）； - 显式地址计算：
getelementptr和load分离，暴露内存访问细节； - 无符号溢出标记：
nsw（No Signed Wrap）告诉优化器“此处有符号溢出是未定义行为，可安全假设不发生”。
这个IR就是优化器的“画布”，所有优化都在此之上涂抹。
3.2 局部优化实战：常量折叠与代数化简如何消灭冗余计算
局部优化只看单个基本块内的指令序列，不关心控制流跳转。我们构造一个极端例子：
int calc() { int x = 10 + 20 * 3; int y = x - 5; int z = y * 1; return z; }生成IR（-O0）：
define dso_local i32 @calc() #0 { entry: %x = add i32 10, 60 ; 20*3被前端常量折叠成60，再算10+60 %y = sub i32 %x, 5 %z = mul i32 %y, 1 ret i32 %z }开启-O1后：
define dso_local i32 @calc() #0 { entry: ret i32 65 ; 直接返回65！ }发生了什么？编译器执行了三步局部优化：
- 常量折叠（Constant Folding）：识别
20 * 3为常量表达式，前端在词法分析阶段就计算为60； - 代数化简（Algebraic Simplification）：
x = 10 + 60→x = 70；y = 70 - 5→y = 65；z = 65 * 1→z = 65； - 无用赋值删除（Dead Store Elimination）：
x,y,z都是局部变量且无副作用，其存储指令被完全移除，只剩ret i32 65。
注意：代数化简不是简单套公式。比如
x * 0会优化为0，但x / 1不会优化为x，因为除零异常是可观察行为，编译器必须保留除法指令以捕获异常。这是语义等价性的硬约束。
实操心得：当你发现某个简单计算在优化后“消失”了，先检查是否触发了常量折叠。我在调试一个配置解析器时，把版本号#define VERSION "1.2.3"硬编码进日志字符串，结果优化后日志里版本号没了——因为printf("Ver: %s", VERSION)被优化成printf("Ver: 1.2.3")，而字符串字面量被合并到只读段，调试器看不到变量名。解决方案：用volatile char ver[] = "1.2.3";强制保留变量实体。
3.3 全局优化核心：公共子表达式消除（CSE）与死代码删除（DCE）
全局优化需要跨基本块分析数据流。回到dotprod函数，我们手动添加一个冗余计算：
int dotprod_v2(int *a, int *b, int n) { int sum = 0; for (int i = 0; i < n; i++) { int temp = a[i] * b[i]; // 显式引入temp sum += temp; if (i % 2 == 0) { sum += temp; // 偶数索引时多加一次 } } return sum; }-O1生成的IR中，a[i] * b[i]的计算只出现一次：
; 在循环体内，只有一处 mul 指令 %mul = mul nsw i32 %load, %load2 ; a[i]*b[i] %add = add nsw i32 %sum.0, %mul ; sum += temp ; 后续 if 分支中，直接复用 %mul %rem = srem i32 %i.0, 2 %cmp = icmp eq i32 %rem, 0 br i1 %cmp, label %if.then, label %if.end if.then: %add3 = add nsw i32 %add, %mul ; sum += temp（复用同一%mul） br label %if.end这就是全局公共子表达式消除（Global CSE）：优化器构建了“表达式哈希表”，对每个load+mul组合计算哈希值，发现两次计算的操作数完全相同（%load和%load2），于是第二处直接复用第一次的结果%mul，避免重复访存和乘法。
而**死代码删除（DCE）**则更隐蔽。假设你在循环里写了：
for (int i = 0; i < n; i++) { int unused = i * i; // 完全没被用到 sum += a[i] * b[i]; }-O1会直接删掉int unused = i * i;对应的全部IR指令，连%i.0的平方计算都不会生成。判断依据是：该指令的计算结果%unused在后续IR中没有任何use（被其他指令作为操作数引用）。
提示：DCE是调试时最大的“幻觉制造者”。你设断点在
int unused = i * i;，却发现断点永远不命中——因为这行代码已被优化器物理删除。解决方案：调试时用-O0 -g，或对特定变量加__attribute__((used))强制保留。
3.4 循环优化实战：循环不变量外提（Loop Invariant Code Motion）
这是性能提升最显著的优化之一。看这个例子：
void process(int *arr, int n, int scale) { int base = 100 * scale; // 循环外计算，但写在循环内 for (int i = 0; i < n; i++) { arr[i] = arr[i] * base + 5; } }-O1生成的IR中，base的计算被移到循环外：
; 循环前 %base = mul nsw i32 100, %scale ; 循环体内 %load = load i32, i32* %arrayidx, align 4 %mul = mul nsw i32 %load, %base ; 复用外部计算的%base %add = add nsw i32 %mul, 5 store i32 %add, i32* %arrayidx, align 4这就是循环不变量外提（LICM）：优化器分析100 * scale的两个操作数100（常量）和%scale（函数参数，在循环中不被修改），判定该表达式在整个循环迭代中值不变，于是将其计算移出循环体，避免每次迭代都重复乘法。
但LICM有严格前提：操作数必须在循环中不可变（invariant）。如果scale是全局变量：
int global_scale; void process_bad(int *arr, int n) { for (int i = 0; i < n; i++) { int base = 100 * global_scale; // global_scale可能被其他线程修改！ arr[i] = arr[i] * base + 5; } }-O1不会外提，因为global_scale的值在循环中可能变化（即使当前函数没改，其他线程可能改）。此时若强制外提，会导致base用旧值计算所有元素，语义错误。编译器会保守地保留循环内计算，除非你显式声明const int* p = &global_scale;或加restrict关键字。
实操心得：我在优化一个图像缩放算法时，把缩放因子scale_x,scale_y作为全局变量传入，结果性能卡在30FPS。改成函数参数后，LICM生效，直接跳到60FPS。根源就是全局变量的别名不确定性阻塞了优化。
4. 常见问题与排查技巧实录：当优化“好心办坏事”时怎么办
4.1 问题速查表：优化引发的典型现象与根因定位
| 现象 | 可能根因 | 快速验证方法 | 解决方案 |
|---|---|---|---|
| 断点失效 | DCE删除了变量/语句；LICM移动了计算位置 | 编译时加-g -O0对比调试信息；用objdump -S看汇编对应行 | 调试用-O0；对关键变量加volatile或__attribute__((used)) |
| 数值结果突变 | 未定义行为（UB）被优化器利用（如有符号溢出、空指针解引用） | 用-fsanitize=undefined编译运行；检查Clang警告-Wsign-conversion | 修复UB：用uint32_t替代int做计数；加if(ptr) *ptr=...判空 |
| 时序敏感功能异常（如硬件寄存器轮询） | 编译器删除“看似无用”的读操作（如while(*reg == 0);） | 查看IR中load指令是否被删；加volatile修饰寄存器指针 | 对硬件地址指针强制volatile int* reg = (volatile int*)0x4000; |
| Release版崩溃，Debug版正常 | 优化暴露了栈溢出、缓冲区越界等隐藏缺陷 | 用-fsanitize=address检测内存错误；-fstack-protector-strong加固栈 | 修复内存错误；增加数组边界检查 |
| 性能不升反降 | 过度展开循环导致指令缓存（I-Cache）失效；寄存器压力过大引发频繁spill | 用perf record -e cycles,instructions对比；禁用特定优化测试 | 用#pragma GCC optimize("no-tree-loop-optimize")局部禁用；调整-funroll-loops参数 |
4.2 独家避坑技巧：三个被文档忽略的实战真相
真相一：-O2不等于“所有优化都开”，它有明确的禁用列表
GCC文档说“-O2开启大部分优化”，但实际它默认禁用：
-fthread-jumps（线程跳转优化）：可能影响调试；-fcrossjumping（跨跳转代码合并）：增加代码大小；-foptimize-sibling-calls（尾递归优化）：某些ABI不兼容。
所以如果你的项目需要极致性能，别盲目信-O2，用gcc -Q --help=optimizers | grep enabled查看当前启用项，再针对性加-fxxx。
真相二：volatile不是万能银弹，滥用会杀死优化
新手常给所有“可能被硬件改”的变量加volatile，结果发现性能暴跌。因为volatile告诉编译器：“每次访问都必须真实读写内存，禁止任何优化”。这意味着：
volatile int* p; for(int i=0;i<1000;i++) sum += *p;→ 1000次内存读，无法合并；- 正确做法：只在必须保证访问顺序和次数的地方用，如
while(*status_reg != READY);，而计算中间结果用普通变量。
真相三：调试信息（DWARF）和优化是天敌，但有折中方案-g生成的调试信息描述的是源码行号与汇编的映射，而优化会打乱指令顺序。-O1还能勉强对应，-O2以上映射就错乱。但我们发现一个技巧：用-g1（最小化调试信息）+-O2，能保留函数名和行号框架，同时避免详细变量位置信息拖慢编译。实测某大型嵌入式项目，编译时间减少35%，GDB仍能准确停在函数入口。
4.3 一个完整排障案例：从“诡异崩溃”到“一行修复”
某工业控制设备固件，在升级GCC 11.2后，某个PID调节函数在-O2下周期性崩溃。现象：gdb显示崩溃在float error = setpoint - current;这一行，但setpoint和current都是合法浮点数。
排查步骤：
- 缩小范围：用
-O1编译，问题消失 → 确认是优化引发； - 检查UB：加
-fsanitize=float-divide-by-zero -fsanitize=float-cast-overflow，运行报错runtime error: value inf is outside the range of representable values of type 'float'； - 定位源头：发现
current来自ADC采样，但某次采样值为0x7F800000（IEEE754的+inf），而原始代码有if (current > 1000.0f) current = 1000.0f;，但优化器将current > 1000.0f判定为“永假”（因+inf > 1000恒真），把整个if删了； - 根因：
+inf比较在C标准中是“未指定行为（unspecified）”，优化器有权假设输入有限； - 修复：改用
isfinite(current)显式检查，该函数被编译器识别为“必须调用”，无法优化删除。
最终修复仅一行：if (!isfinite(current) || current > 1000.0f) current = 1000.0f;。这个案例说明：优化器不是bug制造者，而是UB的“放大镜”。写安全代码，比调优编译选项重要十倍。
5. 工具链深度整合：用现代工具透视优化全过程
5.1 LLVM Toolchain：从IR到汇编的透明化追踪
LLVM提供了业界最清晰的优化可视化链条。以dotprod.c为例，我们可以分步观察优化如何发生：
# 1. 生成未优化IR（-O0） clang -S -emit-llvm -o dotprod_O0.ll dotprod.c # 2. 应用全局优化（-O1的核心Pass） opt -O1 -S dotprod_O0.ll -o dotprod_O1.ll # 3. 查看优化器做了什么（加-print-after-all） opt -O1 -print-after-all dotprod_O0.ll 2>&1 | grep -A5 -B5 "dotprod" # 4. 生成汇编并对比 clang -O1 -S dotprod.c -o dotprod_O1.s clang -O0 -S dotprod.c -o dotprod_O0.s diff dotprod_O0.s dotprod_O1.s-print-after-all会输出每个优化Pass（如GVN、LoopRotate、SROA）作用前后的IR差异。例如，你可能看到：
*** IR Dump After Global Value Numbering *** ; Function Attrs: noinline nounwind optnone uwtable define dso_local i32 @dotprod(i32* %a, i32* %b, i32 %n) #0 { entry: %cmp = icmp slt i32 0, %n br i1 %cmp, label %for.body, label %for.end for.body: %i.0 = phi i32 [ 0, %entry ], [ %inc, %for.body ] %sum.0 = phi i32 [ 0, %entry ], [ %add, %for.body ] %arrayidx = getelementptr inbounds i32, i32* %a, i32 %i.0 %load = load i32, i32* %arrayidx, align 4 %arrayidx1 = getelementptr inbounds i32, i32* %b, i32 %i.0 %load2 = load i32, i32* %arrayidx1, align 4 %mul = mul nsw i32 %load, %load2 %add = add nsw i32 %sum.0, %mul %inc = add nsw i32 %i.0, 1 %exitcond = icmp slt i32 %inc, %n br i1 %exitcond, label %for.body, label %for.end注意：这里还没出现循环展开，说明-O1默认不展开。而-O2会紧接着调用LoopVectorizePass，把循环体向量化。
提示：
opt命令的Pass名是LLVM内部标识，如-loop-vectorize对应向量化，-gvn对应全局值编号（CSE的实现基础）。掌握这些名字，你就能精准控制优化粒度。
5.2 GCC的-fdump系列：窥探GIMPLE和RTL的隐秘世界
GCC的调试输出比LLVM更底层。用-fdump-tree-all可生成数十个中间文件：
dotprod.c.001t.original：原始GIMPLE（类似IR）；dotprod.c.003t.gimple：经过初步优化的GIMPLE；dotprod.c.034t.rtl：RTL（Register Transfer Language），接近汇编的中间表示；dotprod.c.166t.asm：最终汇编。
重点看.gimple文件，它用C-like语法描述IR：
;; Function dotprod (dotprod) ;; enabled by -tree-original { int sum; int i; sum = 0; i = 0; goto <bb 2>; <bb 2>: if (i < n) goto <bb 3>; else goto <bb 4>; <bb 3>: sum = sum + a[i] * b[i]; i = i + 1; goto <bb 2>; <bb 4>: return sum; }这个GIMPLE清晰展示了循环结构和变量依赖。而.rtl文件则暴露了寄存器分配细节，如(set (reg:SI 100) (plus:SI (reg:SI 99) (const_int 1)))表示r100 = r99 + 1。
实操心得：我在分析一个内存拷贝函数时，发现-O2生成的汇编用了rep movsb指令，但-O3却退化成循环。用-fdump-rtl-expand发现：-O3启用了-ftree-vectorize，但因源/目标地址对齐未知，向量化失败，回退到标量循环。而-O2的-fno-tree-vectorize反而让-march=native的rep movsb优化生效。这提醒我们：优化选项是博弈，不是线性增强。
5.3 性能剖析闭环：用perf和FlameGraph验证优化实效
优化不能只看IR，必须落到真实硬件。我们用perf验证dotprod的优化效果：
# 编译两个版本 gcc -O0 -o dotprod_O0 dotprod.c gcc -O2 -o dotprod_O2 dotprod.c # 用perf采集10秒性能数据 perf record -e cycles,instructions,cache-misses -g ./dotprod_O0 1000000 perf record -e cycles,instructions,cache-misses -g ./dotprod_O2 1000000 # 生成火焰图 perf script | stackcollapse-perf.pl | flamegraph.pl > perf_O0.svg perf script | stackcollapse-perf.pl | flamegraph.pl > perf_O2.svg对比火焰图会发现：
-O0版本：dotprod函数帧占据80%宽度，其中load和mul指令占主要时间；-O2版本：dotprod帧变窄，且出现__memcpy_avx512调用（因循环被识别为内存拷贝模式）；cache-misses指标：-O2版本下降40%，因向量化减少了内存访问次数。
这才是优化的终极验证：IR的简洁，必须转化为CPU周期的节省。我见过太多团队花一周优化IR，结果perf显示L1缓存未命中率反而上升——因为过度展开循环导致指令缓存失效。记住：编译器优化是手段，硬件执行效率才是目的。
6. 优化策略选择指南：不同场景下的务实取舍
6.1 嵌入式资源受限场景：小代码 vs 快速度的权衡
在MCU（如ARM Cortex-M4）上，Flash空间常比CPU时间更宝贵。此时-Os（optimize for size）往往比-O2更优。它启用：
- 函数内联裁剪：只内联小于10行的函数；
- 循环展开抑制：避免代码膨胀；
- Tail Call优化：将尾递归转为跳转，省栈空间。
但要注意陷阱：-Os会禁用-funroll-loops，而某些DSP算法（如FFT蝶形运算）展开后能提升40%速度。我们的做法是：对核心算法函数，用#pragma GCC optimize("unroll-loops")局部开启，其余代码保持-Os。
6.2 高性能计算场景：向量化与并行化的协同
HPC代码（如矩阵乘）需主动引导优化器。除了-O3 -march=native，关键技巧：
- 数据对齐：用
__attribute__((aligned(64))) float A[1024];确保AVX-512指令能高效加载； - 循环提示：
#pragma GCC ivdep告诉编译器忽略循环间依赖（需确认安全）； - 数组标注：`void gemm(float* __restrict A, float* __restrict B
