不同文件夹下的相同源码如何复用GCC PGO采集的剖面数据

结论：该操作完全可行。

你遇到的路径不匹配报错，本质是GCC PGO的默认路径校验规则导致的：编译插桩版本时，GCC会默认把每个编译单元的源文件绝对路径写入剖面数据元信息，后续用剖面数据做优化构建时，会直接拿当前编译的源文件绝对路径去剖面数据里做字符串匹配，哪怕两份源码内容完全一致，只要路径字符串不一样，就会提示找不到对应剖面数据，无法触发PGO优化。

你可以根据自己的场景选下面任意一种方案解决：

• 方案一（推荐，适合还没做插桩编译的场景）：编译插桩版本和后续优化版本时，都加上-fprofile-note-path=./pgo_root参数，指定剖面元信息、运行时采集的数据都存在相对路径目录下，不记录绝对路径，只要两次编译的目录相对结构一致，就不会出现路径不匹配问题。
• 方案二（适合已经跑完插桩、采集完剖面数据不想重跑的场景）：用GCC自带的gcov-tool批量改写已有剖面数据里的源路径前缀，命令格式如下：

gcov-tool merge -o <新剖面数据输出目录> --rewrite-sources="<A/src的绝对路径前缀>=<B/src的绝对路径前缀>" <原有剖面数据所在目录>

比如原插桩编译时的源码根路径是/opt/work/A/src，新的优化编译源码根路径是/opt/work/B/src，替换对应前缀后生成的新剖面数据，就能直接给B路径下的构建流程使用。

• 方案三（无需修改已有剖面数据）：在B路径下做优化编译时，加上-fprofile-prefix-map=<A/src的绝对路径前缀>=<B/src的绝对路径前缀>编译参数，告诉GCC在匹配剖面数据时，先把当前源码路径的B前缀替换成A前缀再做匹配，也能绕过路径校验。

注意：无论用哪种方案，必须保证插桩编译和优化编译使用的源码内容、非PGO相关的编译选项完全一致，否则即使路径匹配成功，也可能因为剖面数据和实际代码逻辑不匹配，导致优化后程序性能下降甚至运行异常。

内容的提问来源于stack exchange，提问作者Dan M.