PGO and BOLT

[lfeng14]

阶段	关键位置	说明
插桩 (Gen)	Transforms/Instrumentation/PGOInstrumentation.cpp	插入 increment 内部函数。
运行时 (RT)	compiler-rt/lib/profile/	内存计数及文件导出。
解析 (Data)	ProfileData/InstrProfReader.cpp	将二进制解析为编译器可读结构。
加载 (Use)	Transforms/Instrumentation/PGOInstrumentation.cpp	将数据转化为 !prof 元数据。
应用 (BFI/BPI)	Analysis/BlockFrequencyInfo.cpp	为后续优化（内联、解循环）提供决策依据。

阅读源码时，建议从 PGOInstrumentation.cpp 开始，搜索 PGOInstrumentationGen（生成模式）和 PGOInstrumentationUse（使用模式），这是整个中端 PGO 的“大脑”。

这两者属于“反馈导向优化”的两个阶段：PGO 作用于编译期，而 BOLT 作用于链接后（二进制期）。

以下我为你梳理的分享大纲及对应的英文权威资料支撑：

---

1. 使用方式介绍 (Usage Workflow)

PGO 和 BOLT 的核心逻辑都是“采样-反馈-重编”。

PGO 的三部曲

1. Instrumentation (插桩): clang -fprofile-generate。编译器在基础块（Basic Block）入口插入计数器。
2. Training (训练): 运行生成的程序，产生 .profraw 文件。
3. Optimization (优化): clang -fprofile-use。编译器根据 profile 数据进行内联、循环展开等决策。

• 进阶： AutoFDO / Sample-PGO。无需插桩，直接通过 perf 采样运行中的程序（对生产环境影响更小）。

BOLT 的流程

1. Collect Profile: 使用 perf record -e cycles:u -j any,u -- ./main 采集原始数据。
2. Convert Profile: 使用 perf2bolt 将数据转为 BOLT 可识别的格式。
3. Optimize: llvm-bolt main -data main.fdata -o main.bolt -reorder-blocks=ext-tsp -reorder-functions=hfsort -split-functions -indirect-calls=jt。

英文资料支撑：

• LLVM 官方文档: [UsersManual for PGO](https://clang.llvm.org/docs/UsersManual.html#profile-guided-optimization)
• BOLT GitHub 官方指南: [BOLT Usage Guide](https://github.com/llvm/llvm-project/tree/main/bolt)

---

2. 原理简单介绍 (Core Principles)

PGO: 逻辑层优化

PGO 主要解决的是编译器在编译时无法确定的概率问题：

• Inline Tuning: 优先内联热点路径上的函数。
• Virtual Call Speculation: 如果某个虚函数 99% 指向同一个类，将其改为直接调用。
• Loop Unrolling: 根据迭代次数决定展开策略。

BOLT: 物理层布局优化

BOLT 认为链接后的二进制文件在物理空间上仍不完美：

• Basic Block Reordering (BB 重排): 将热的基础块放在一起，减少 CPU 的跳转开销（Branch Misprediction）并提高 I-Cache 命中率。
• Function Splitting (冷热分离): 把函数中永远不会跑到的 if(error) 代码块搬到二进制文件的末尾，让热代码更紧凑。
• PLT/Indirect Call Optimization: 优化间接跳转。

英文资料支撑：

• Meta 的核心论文 (必读): [BOLT: A Practical Binary Optimizer for Data Centers and Beyond](https://arxiv.org/abs/1807.03149)
• Google 的相关论文: [Propeller: Profile-guided Post-link Optimization](https://research.google/pubs/pub49153/) (Propeller 是 BOLT 的竞争对手，原理相似)。

---

3. 常见问题解答 (Q&A)

Q: 代码修改后，旧的 Profile 还能用吗？(Profile Drift/Bitrot)

• 解答: LLVM 有一定的容错机制（基于哈希匹配）。小范围的逻辑修改不影响大部分热点块匹配。但如果函数结构剧变，编译器会报 profile-out-of-date 警告并回退到传统启发式优化。
• 策略: 定期（如每周）在生产环境中重新采样更新 Profile。

Q: PGO + BOLT 会有叠加增益吗？

• 解答: 会。PGO 优化的是中端 IR 的逻辑流，BOLT 优化的是最终机器码的布局。通常 PGO 能带来 5-10% 提升，在此基础上 BOLT 能再压榨出 5-10%。

Q: 性能劣化风险？

• 解答: 最大的风险在于“训练集（Training Set）”与“实际负载（Production Workload）”不匹配。如果训练时跑的是测例 A，实际跑的是场景 B，优化可能会适得其反。

---

4. 有意思的进阶点 (Extra Points)

1. I-Cache 的“黄金法则”

你可以分享为什么“代码紧凑”对现代 CPU 如此重要。在 ARMv9 这种深流水线架构中，一次 I-Cache Miss 带来的 Pipeline Flush 代价极大。BOLT 通过减少跨 Cache Line 的跳转，本质上是在做 Instruction Fetch Efficiency 的优化。

2. Context-Sensitive Sample PGO (CSSPGO)

这是 LLVM 比较新的特性。传统的 PGO 无法区分同一个函数在不同调用栈下的行为，CSSPGO 引入了调用链上下文，使得内联决策更精准。这对于 AlphaFold3 这种有复杂调用链的高性能计算非常有效。

3. "The Performance Tax"

可以提一下插桩 PGO 带来的编译时长和运行开销（2x-10x 变慢），从而引出为什么 BOLT 这种基于 perf 采样的无损方式在大型互联网公司（如 Meta, Google, 字节）更受欢迎。

---

5. 英文资源汇总清单

1. Talks (YouTube):
   • BOLT: A Practical Binary Optimizer (Maksim Panchenko, LLVM Developers' Meeting).
   • Advanced PGO in LLVM (Sergey Panteleev).
2. Blogs:
   • Meta Engineering Blog: [Accelerating Facebook’s infrastructure with BOLT](https://engineering.fb.com/2018/06/19/data-infrastructure/accelerating-facebook-s-infrastructure-with-bolt/) (这是 BOLT 的成名作)。
   • Phoronix: 搜索 "PGO BOLT Benchmarks"，可以看到各种 CPU（包括 ARM）上的实测对比数据图表。
3. RFCs:
   • LLVM 社区关于 CSSPGO 的讨论: [RFC: Context-Sensitive Sample PGO](https://lists.llvm.org/pipermail/llvm-dev/2020-May/141671.html)。

建议： 在组内分享时，可以现场展示一个简单的 objdump 对比，展示 BOLT 优化前和优化后，热点 Basic Block 物理位置的移动，这种视觉冲击力对开发者来说非常直观。

祝你分享顺利！如果需要针对 ARM 平台的特定优化数据（比如在 Neoverse N1/V1 上的表现），可以再告诉我。

---

你的分析非常专业且到位，直戳了 PGO 在工业界大规模应用时的核心痛点——Profile Drift（数据漂移）。

你的结论是合理的：IR 插桩确实比前端插桩对“代码行号变化”有更强的容忍度。

为了让你的组内分享更有深度，我们可以从底层机制上把这个问题拆解得更透彻一些：

---

1. 为什么 IR 插桩（IR-level PGO）更鲁棒？

LLVM 默认推荐使用 IR 插桩（-fprofile-generate），其核心匹配逻辑不是靠行号，而是靠 函数名称 + 结构哈希（Structural Hash）。

• 匹配流程：
  1. 编译器为每个函数生成一个 CFG（控制流图）哈希值。这个哈希反映了函数内部有多少个基本块（Basic Block），以及它们之间的跳转关系（if/else, loop）。
  2. 即使你在头文件里增加了一个函数，导致下游 .cpp 文件的行号整体下移，但对于原有的函数 A 来说，它的 CFG 结构没变，函数名也没变。
  3. 加载 Profile 时，LLVM 发现函数 A 的哈希依然匹配，就能完美地把热度数据填充回去。
• 结论：在头文件增加函数、在函数外部增加注释、改变不含逻辑的代码位置，对 IR PGO 几乎没有影响。

---

2. 为什么前端插桩（Frontend PGO）更脆弱？

前端插桩（-fprofile-instr-generate）是由 Clang 负责的，它更贴近源码。

• 匹配逻辑：它在很大程度上依赖于源码的 Source Locations（文件路径+行号+列号）。
• 失效场景：
  • 如果你在头文件插入了一个函数定义，所有引用该头文件的 .cpp 文件在预处理后，原有代码的行号都变了。
  • 前端 PGO 可能会因为找不到对应的行号，导致大量热度数据无法映射（Mismatched），从而回退到普通的启发式优化。
• 分析合理性：你的分析完全正确。这就是为什么在生产流水线（如生产环境的每小时滚动构建）中，大家几乎都转向 IR PGO 或基于硬件采样的 AutoFDO（BOLT 也属于这一类）。

---

3. 什么是真正意义上的“大范围修改”？

在 IR PGO 的语境下，以下操作会被视为“大改”，导致 Profile 失效：

1. 改变了控制流图（CFG）：
   • 比如你把一个 if 改成了 switch，或者在循环里增加了一个 break 分支。这会导致函数的哈希值彻底改变，编译器会报告 Function hash mismatch。
2. 宏展开的变化：
   • 如果你修改了一个被广泛使用的宏，且这个宏包含逻辑判断。宏展开后会改变所有相关函数的 CFG 结构。
3. 内联决策的连锁反应：
   • 虽然 PGO 帮助内联，但如果代码改动导致某些核心函数被编译器认为“不再适合内联”，那么整个后端的 Profile 映射可能会出现偏差。

---

4. 补充一个分享亮点：BOLT 对修改的容忍度

由于你在分享中还会提到 BOLT，这里有一个非常有意思的对比：

• PGO 容忍度较高：因为它是在源码/IR 层面匹配，有函数名和结构作为锚点。
• BOLT 容忍度极低：BOLT 作用于二进制。如果你修改了代码并重新编译，函数的地址、寄存器分配、偏移量都会发生剧变。
• 实战结论：
  • PGO Profile 可以跨小版本使用（比如周一采样的 profile，周三的代码还能用，只是效果稍微劣化）。
  • BOLT Profile 通常要求 Binary 必须完全匹配。一旦代码改了，你就得针对新的二进制重新跑一次 perf 采样，否则 BOLT 无法处理。

---

给分享内容的填充建议：

你可以增加一张对比表，展示不同优化手段对“代码变动”的敏感程度：

优化技术	匹配锚点	对行号偏移敏感度	对逻辑改动敏感度
Frontend PGO	文件名 + 行号	高	高
IR PGO	函数名 + CFG 哈希	极低	高
Sample PGO (AutoFDO)	函数名 + 相对偏移	低	中
BOLT	二进制地址 / 符号偏移	极高 (必须重新构建)	极高

其他有意思的点：

• Fuzzy Matching（模糊匹配）：LLVM 社区一直在尝试做“模糊 Profile 匹配”，即逻辑变了一点点，能不能通过类似相似度算法把数据“凑合”上去？这对大型项目的开发效率很有帮助。
• Profile Stale 度量：介绍一下如何监控 Profile 的失效比例（Mismatch Rate）。在华为的大规模工程中，这个指标是衡量 CI/CD 流水线健康度的关键。

这样分析下来，你的分享不仅有深度，而且非常贴合生产实践！

[lfeng14]

结合pdf：
https://github.com/lfeng14/llvm-note/blob/main/pgo-tools/llvm-pgo.md

[lfeng14]

源码修改是怎么影响pgo效果的 ?

• 先说结论：中端插桩，只有影响到cfg这时才告警hash值匹配不上，所以实际调优时如果修改了热点函数的cfg那么会影响到profile效果；但是同样的修改前端插桩居然没有报告

• 中端复现流程：

  clang -O2 -fprofile-generate code.c -o sample.exe
  ./sample.exe
  llvm-profdata merge  default_16001431144870961557_0.profraw  -o default_16001431144870961557_0.profdata
  
  llvm-profdata merge  default_16001431144870961557_0.profraw  -o default_16001431144870961557_0.profdata.txt -text
  
  clang -O2 -fprofile-use=default_16001431144870961557_0.profdata code.c -o pgo.exe   -Wno-implicit-function-declaration
  

• 前端插桩

   clang -O2 -fprofile-instr-generate code.c -o sample.exe 
   ./sample.exe 
   llvm-profdata merge  default.profraw  -o default.profdata
  
   vi code.c
   clang -O2 -fprofile-instr-use=code.profdata code.c -o pgo.exe   -Wno-implicit-function-declaration
  
  

• 例子

  #include <stdio.h>
  #include <stdio.h>
  #include <stdlib.h>
  #include <sys/time.h>
  #include <assert.h>
  #include <unistd.h>
  #define ARRAY_LEN 8000
  int data[ARRAY_LEN];
  static struct timeval tm1;
  static inline void start() { gettimeofday(&tm1, NULL); }
  static inline void stop() {
  struct timeval tm2;
  gettimeofday(&tm2, NULL);
  unsigned long long t =
      1000 * (tm2.tv_sec - tm1.tv_sec) + (tm2.tv_usec - tm1.tv_usec) / 1000;
  printf("Average: %llu ms\n", t);
  }
  void swap_int(int *a,int *b) {
  int c = *a;
  *a = *b;
  *b = c;
  }
  void bubble_sort(int *a, int n) {
  int i, t, s = 1;
  for (i = 0; i < n -1; i++) {
      for(int j=i+1;j<n-1;j++)
      if (a[i] < a[j]) {
          swap_int(&a[i],&a[j]);
      }
  }
     if(n > 9) {
        printf("345"); // 这一行触发了cfg变化
        return;
     }
     printf("124"); printf("124");
  
  }
  void sort_array() {
  printf("Bubble sorting array of %d elements\n", ARRAY_LEN);
  bubble_sort(data, ARRAY_LEN);
  }
  void get_data() {
  for (int i = 0; i < ARRAY_LEN; ++i) {
      data[i] = i;
  }
  #ifdef __aarch64__
  asm volatile ("DMB SY");
  #endif
  }
  int main() {
  get_data();
  start();
  sort_array();
  stop();
  return 0;
  }
  

• 计算hash值

  // Compute Hash value for the CFG: the lower 32 bits are CRC32 of the index
  // value of each BB in the CFG. The higher 32 bits record the number of edges
  // preceded by the number of indirect calls.
  // This is derived from FuncPGOInstrumentation<Edge, BBInfo>::computeCFGHash().
  void SampleProfileProber::computeCFGHash(
      const DenseSet<BasicBlock *> &BlocksToIgnore) {
    std::vector<uint8_t> Indexes;
    JamCRC JC;
    for (auto &BB : *F) {
      if (BlocksToIgnore.contains(&BB))
        continue;
  
      auto *TI = getOriginalTerminator(&BB, BlocksToIgnore);
      for (unsigned I = 0, E = TI->getNumSuccessors(); I != E; ++I) {
        auto *Succ = TI->getSuccessor(I);
        auto Index = getBlockId(Succ);
        // Ingore ignored-block(zero ID) to avoid unstable checksum.
        if (Index == 0)
          continue;
        for (int J = 0; J < 4; J++)
          Indexes.push_back((uint8_t)(Index >> (J * 8)));
      }
    }
  
    JC.update(Indexes);
  
    FunctionHash = (uint64_t)CallProbeIds.size() << 48 |
                   (uint64_t)Indexes.size() << 32 | JC.getCRC();
    // Reserve bit 60-63 for other information purpose.
    FunctionHash &= 0x0FFFFFFFFFFFFFFF;
    assert(FunctionHash && "Function checksum should not be zero");
    LLVM_DEBUG(dbgs() << "\nFunction Hash Computation for " << F->getName()
                      << ":\n"
                      << " CRC = " << JC.getCRC() << ", Edges = "
                      << Indexes.size() << ", ICSites = " << CallProbeIds.size()
                      << ", Hash = " << FunctionHash << "\n");
  }  
  

参考

• https://deepwiki.com/search/fprofilegenerate-pgo-func-hash_978719b7-147e-4dd1-a2cc-de9313b3b730