4. 编译器优化概览：编译器如何感知缓存？优化流程与IR表示

好，咱们进入正题。这一章我想聊聊编译器到底是怎么“看到”缓存的。很多人觉得编译器就是个翻译官，把高级语言转成机器码就完事了。其实不然。编译器在背后做了大量针对缓存的工作，只是你感觉不到而已。

我个人习惯把编译器优化分成三个阶段：前端分析、中端变换、后端生成。缓存优化主要发生在中端和后端。说白了，就是编译器在生成代码之前，先琢磨一下你的数据是怎么访问的，然后想办法让它们待在缓存里别出来。

4.1 编译器眼中的缓存：抽象层级与IR

编译器内部用IR（中间表示）来代表你的程序。IR有很多种，比如LLVM的LLVM IR、GCC的GIMPLE、还有更底层的机器相关IR。缓存优化主要发生在机器相关IR这一层，因为这时候编译器已经知道目标CPU的缓存大小、行大小、关联度等信息了。

举个例子，LLVM的IR里有一个叫llvm.memcpy的内建函数。编译器看到这个，就知道你要拷贝一大块内存。它会根据拷贝的大小，决定是用rep movsb（逐字节拷贝）还是用movdqa（SIMD向量拷贝）。为什么？因为rep movsb在某些CPU上会触发硬件预取，对缓存更友好。我在项目中遇到过，同样的memcpy，换一种实现方式，性能差了3倍。

; LLVM IR示例：memcpy的两种表示
; 方式1：直接调用memcpy
%dest = call i8* @memcpy(i8* %dst, i8* %src, i64 1024)

; 方式2：展开为循环（编译器优化后）
for.body:
  %i = phi i64 [ 0, %entry ], [ %next, %for.body ]
  %src_ptr = getelementptr i8, i8* %src, i64 %i
  %dst_ptr = getelementptr i8, i8* %dst, i64 %i
  %val = load i8, i8* %src_ptr
  store i8 %val, i8* %dst_ptr
  %next = add i64 %i, 1
  %done = icmp eq i64 %next, 1024
  br i1 %done, label %exit, label %for.body

你想想看，方式2的循环每次只加载一个字节，缓存利用率极低。编译器会把它优化成一次加载16字节或32字节，这就是循环展开+向量化。嗯，这里要注意，不是所有循环都能展开，编译器会做依赖分析。

4.2 优化流程：从源码到机器码的缓存感知

编译器的优化流程大致是这样的：

1. 词法/语法分析：生成AST（抽象语法树）。这时候编译器还不知道缓存是什么。
2. 语义分析：检查类型、作用域等。还是跟缓存没关系。
3. 生成中间表示（IR）：比如LLVM IR。这时候开始做一些与机器无关的优化，比如常量折叠、死代码消除。
4. 机器相关优化：缓存优化就发生在这里。编译器会做：
   • 循环变换：循环交换、循环分块、循环展开
   • 数据布局优化：结构体字段重排、数组填充
   • 指令调度：把内存访问指令提前，隐藏延迟
   • 预取插入：插入prefetch指令
5. 寄存器分配：把频繁使用的变量放到寄存器里，减少内存访问。
6. 指令选择与调度：生成最终机器码。

我曾经踩过一个坑：在ARM平台上，编译器默认没有开启循环分块优化。我写了一个矩阵乘法，数据量刚好超过L2缓存大小。结果性能惨不忍睹。后来我手动加了-fopt-info-loop一看，编译器根本没做分块。加上-floop-block之后，性能提升了4倍。

4.3 缓存感知优化的核心IR变换

编译器在IR层面做缓存优化，主要靠以下几种变换：

变换名称	IR层面的操作	缓存收益
循环交换	交换嵌套循环的次序	让内层循环访问连续内存，提高空间局部性
循环分块	将大循环切分成小块	让工作集适配缓存大小，减少缓存缺失
循环展开	复制循环体多次	减少分支开销，增加指令级并行，隐藏内存延迟
结构体拆分	将结构体按字段拆分成多个数组	只访问需要的字段，减少缓存行污染
数组填充	在数组行之间插入无用元素	避免缓存行冲突（伪共享）

举个例子，循环交换在IR里长什么样？

; 原始代码：外层循环遍历i，内层遍历j（按列访问）
for.i:
  %i = phi i32 [ 0, %entry ], [ %i.next, %for.i.end ]
  for.j:
    %j = phi i32 [ 0, %for.i ], [ %j.next, %for.j ]
    %idx = getelementptr [1024 x i32], [1024 x i32]* %A, i32 %j, i32 %i
    ; 注意：这里访问A[j][i]，不是连续的！
    ...

; 优化后：交换循环次序，变成按行访问
for.j:
  %j = phi i32 [ 0, %entry ], [ %j.next, %for.j.end ]
  for.i:
    %i = phi i32 [ 0, %for.j ], [ %i.next, %for.i ]
    %idx = getelementptr [1024 x i32], [1024 x i32]* %A, i32 %j, i32 %i
    ; 现在访问A[j][i]是连续的（行优先）
    ...

你想想看，C语言是行优先存储。如果内层循环遍历列，每次访问都要跨过一整行，缓存行里只取一个元素，剩下的全浪费了。交换之后，内层循环连续访问同一行的元素，缓存命中率直线上升。

4.4 编译器如何“知道”缓存参数？

这个问题很有意思。编译器其实不是靠猜的。它通过两种方式获取缓存信息：

• 静态配置：编译时指定目标CPU架构（比如-march=haswell），编译器会查表得到L1/L2/L3的大小、行大小、关联度等。
• 运行时探测：有些编译器（比如Intel ICC）会在程序启动时执行一段微基准测试，动态测量缓存大小和延迟。嗯，这个做法比较激进，但效果很好。

我记得在优化一个图像处理算法时，目标平台是ARM Cortex-A72。我用了-mcpu=cortex-a72，编译器自动把循环分块大小设成了64（L1缓存行大小）。结果性能比默认的-mcpu=generic提升了30%。

4.5 一个完整的优化案例：矩阵乘法

咱们来看一个具体的例子。假设你要写一个矩阵乘法：

// 原始代码：三重循环，最内层访问C[i][j] += A[i][k] * B[k][j]
for (int i = 0; i < N; i++) {
  for (int j = 0; j < N; j++) {
    for (int k = 0; k < N; k++) {
      C[i][j] += A[i][k] * B[k][j];
    }
  }
}

这个代码的问题在于：内层循环k遍历时，B[k][j]的访问是按列的，每次都要跳过一整行。当N很大时（比如1024），B矩阵完全不在缓存里，每次访问都是缓存缺失。

编译器会怎么做？它会做循环分块：

// 优化后：分块大小为BLOCK_SIZE（通常等于L1缓存行大小）
for (int i = 0; i < N; i += BLOCK_SIZE) {
  for (int j = 0; j < N; j += BLOCK_SIZE) {
    for (int k = 0; k < N; k += BLOCK_SIZE) {
      // 现在处理一个BLOCK_SIZE x BLOCK_SIZE的小块
      for (int ii = i; ii < i + BLOCK_SIZE; ii++) {
        for (int jj = j; jj < j + BLOCK_SIZE; jj++) {
          for (int kk = k; kk < k + BLOCK_SIZE; kk++) {
            C[ii][jj] += A[ii][kk] * B[kk][jj];
          }
        }
      }
    }
  }
}

分块之后，A和B的小块都能放进L1缓存里。内层循环访问时，大部分数据都在缓存中。我在项目中测试过，分块后的矩阵乘法比原始版本快了6倍（N=1024，BLOCK_SIZE=64）。

编译器在IR里做这个变换时，会先分析循环的依赖关系，确认可以分块。然后它会插入新的循环边界计算，生成新的IR节点。最后在指令选择阶段，它会尽量使用SIMD指令来加速小块内的计算。

4.6 总结：编译器缓存优化的局限性

说了这么多，我得泼点冷水。编译器不是万能的。它有几个硬伤：

• 无法预测运行时数据：如果数据访问模式取决于输入值（比如链表遍历），编译器没法优化。
• 保守的依赖分析：为了安全，编译器假设指针可能别名，导致很多优化不敢做。
• 缺乏全局视角：编译器一次只优化一个函数，跨函数的缓存优化很难做。

所以，我的建议是：把编译器当成一个聪明的助手，但不是万能的神。对于关键代码，先用-O2或-O3编译，然后用性能分析工具（perf、valgrind）看看缓存缺失率。如果太高，再手动改写代码。

我曾经接手过一个项目，代码里到处都是restrict关键字。我问前任为什么这么写，他说「为了让编译器做更多优化」。结果我一看，很多地方restrict用错了，反而导致编译器生成了错误的代码。嗯，这里要注意：restrict是承诺，不是建议。用错了会出bug。

好了，这一章就到这里。记住：编译器感知缓存的核心是IR变换，而你要做的，就是写出让编译器容易优化的代码。

---