有哪些规范化方法可分析检视PGO编译器的优化改动？

以下方案均不依赖原始编译器内部结构dump，可直接梳理全量PGO生效的优化点，适配数据库类大型项目的分析需求：

• 第一步先搭建无偏差对照基线
  同一份源码、完全一致的基础编译选项，分别产出无PGO的基线构建产物和PGO优化构建产物，两个版本统一加-g（带调试信息，不影响优化逻辑）、-frecord-gcc-switches标记编译参数，确保除PGO相关逻辑外无任何变量干扰。
• 从二进制产物倒推已落地的优化改动
  所有最终生效的PGO优化都会落到二进制上，从产物反推不会出现“编译器日志里记了优化但实际没生效”的偏差：
  • 用readelf -S对比两个版本的段布局，统计热代码段、冷代码段的划分，函数排布顺序变化，这部分对应PGO最核心的代码布局类优化（热函数前置、指令地址对齐、冷代码拆分到独立段减少缓存污染）。
  • 用nm对比两个版本的符号表，标记出三类明确的PGO改动：基线版本存在但PGO版本消失的符号（PGO调整内联阈值后被内联）、PGO版本新增的带.hot/.cold后缀的符号（函数按执行频率做了热冷拆分）、符号属性从弱符号/本地符号调整为全局符号/本地符号的条目（对应PGO调整的符号可见性优化）。
  • 用objdump -d反汇编核心模块（比如测试中收益最高的聚合模块），对比分支跳转指令的偏移、循环展开的指令数、内存访问指令的排布，对应PGO做的分支布局调整、循环针对性展开、访存优化类改动。
• 用编译器原生结构化报告直接导出优化决策
  不需要解析cgraph这类原始内部结构，编译器自带专门面向开发者的优化审计参数：
  • 编译时加-fprofile-report，编译完成后会直接输出结构化的PGO优化统计，包含热冷拆分的函数数量、分支布局调整的条目数、基于剖面数据修改的内联决策数、循环展开调整的条目，每一项都会标注对应的源文件、行号、函数名，可直接按模块筛选。
  • 两个版本编译时都加-fopt-info-optimized，输出所有优化pass的具体动作，直接diff两份输出，过滤掉共有的优化项，剩下的就是PGO引入的专属优化改动，可直接整理成清单。
  • 用gcov（GCC）或llvm-profdata show（Clang）导出PGO使用的剖面数据，拿到每个函数的执行计数、分支跳转概率、循环迭代次数分布，可直接对应每个优化的触发依据：比如聚合模块中某分支的taken率达97%，PGO就会将其调整为fallthrough路径减少分支预测开销，对应关系可直接匹配。
• 结合性能计数完成优化归因
  用和性能测试完全一致的负载，在两个构建版本上分别用perf record -e branches,branch-misses,i-cache-loads,i-cache-load-misses,cycles采集硬件性能计数器，把计数器的差异和之前定位到的二进制改动、优化决策一一对应，就能明确每一项PGO优化带来的实际收益，也能定位到PGO可能引入的负优化点（比如部分冷路径被错误标记为热路径带来的缓存开销）。

不建议从编译器内部dump（比如cgraph dump）从上往下梳理，这类原始信息是给编译器开发者排查编译器本身问题用的，信息冗余度极高，大型项目里光解析dump就要花数天时间，还容易把没落到最终产物的无效优化决策算进来。从最终产物倒推、结合结构化报告的路径，在数据库这类百万行级代码的项目里，通常1-2天就能梳理完全量PGO优化改动。

内容的提问来源于stack exchange，提问作者Bouncner