-O2/-O3是GCC/Clang触发自动循环展开的必要条件；-funroll-loops（GCC）或-floop-unroll-and-jam（Clang）可强制启用，但仅对静态可推导、无副作用的循环生效。
编译器自动展开循环时，gcc 和 clang 的关键开关是什么
现代 C++ 编译器默认会在优化级别足够高时尝试循环展开，但不会无条件展开所有循环。核心控制开关是优化等级和特定属性/指令，而非手动改写代码。
-
-O2或-O3是触发自动展开的必要条件；-O1通常不启用，-O0完全禁用 -
-funroll-loops（GCC）或-floop-unroll-and-jam（Clang）可强制启用，但仅对“适合展开”的循环生效——比如迭代次数可静态推导、无副作用、无分支跳转 - 加了
#pragma GCC unroll N或[[gnu::unroll(N)]]可显式提示编译器展开N次，但若N超出实际迭代数，多余副本会被优化掉；若N = 0，则交由编译器自主决策
手写展开循环前，先确认是否真有必要
人工展开常适得其反：增大指令缓存压力、干扰 CPU 分支预测、掩盖真实数据依赖。它只在极少数场景下有效，比如固定小尺寸向量运算、嵌入式 tight-loop、或编译器无法推断边界的情况。
- 典型有效场景：
for (int i = 0; i —— 迭代数已知且很小，编译器通常能处理；但若写成 <code>for (int i = 0; i 且 <code>N是运行时变量，编译器大概率放弃展开 - 常见错误：把
for (int i = 0; i 改成四次重复语句却忘了处理 <code>n % 4的余数，导致逻辑错误 - 性能陷阱：展开后寄存器压力上升，可能引发更多 spill，反而变慢；可用
perf stat -e instructions,branches,branch-misses ./a.out对比指令数与分支误预测率
__attribute__((optimize("unroll-loops"))) 的作用范围和限制
这个函数级属性仅影响该函数内符合展开条件的循环，不是全局开关，也不能覆盖语言约束（如循环体含 setjmp、volatile 访问或异常抛出）。
- 仅 GCC 支持，Clang 不识别；MSVC 对应的是
#pragma loop(unroll) - 若循环中调用了非内联函数，编译器大概率放弃展开，因为无法确认副作用
- 对模板实例化函数生效，但需确保属性写在实例化后的函数声明上，而非模板定义本身
- 示例：
__attribute__((optimize("unroll-loops"))) void process(float* a, int n) { for (int i = 0; i < n; ++i) a[i] *= 2.0f; }——仅当n在调用点为常量（如process(arr, 8)）时才可能真正展开
检查是否真的展开了：看汇编，别信直觉
所谓“加了 -funroll-loops 就一定展开”是误解。最终是否生成展开代码，必须查生成的汇编。
立即学习“C++免费学习笔记（深入）”；
- 用
g++ -O3 -S -o loop.s loop.cpp生成汇编，搜索循环标签（如.LBB0_2:）及重复出现的movss/addss等指令块 - 若看到类似
addss xmm0, DWORD PTR [rax]后紧跟三次相同指令（地址偏移 +4/+8/+12），说明已展开；若只有单条指令加add rax, 4和cmp跳转，则未展开 - Clang 用户可加
-mllvm --unroll-threshold=500提高阈值，但超过 100 次展开往往得不偿失
编译器做循环展开的前提是它能确信安全且有益，而人眼判断“这段循环应该展开”常常忽略了流水线深度、uop cache 容量、或内存访问模式这些底层制约。最稳妥的做法，是先用 -O3 编译，再用 perf 和 objdump 验证，而不是一上来就加 pragma 或手撕循环。
