-fprofile-use 和-fauto-profile 有什么区别？
文档是这样说的：
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options
-fprofile-使用
-fprofile-use=路径
启用以配置文件反馈为导向的优化，以及以下通常只有在配置文件反馈可用时才会有利可图的优化：[...]
如果指定了路径，GCC 会查看路径以查找配置文件反馈数据文件。请参阅 -fprofile-dir。
在它下面
-fauto 配置文件
-fauto-profile=路径
启用基于采样的反馈导向优化，以及以下通常仅在配置文件反馈可用时才能盈利的优化：[...]
path 是包含 AutoFDO 配置文件信息的文件的名称。如果省略，则默认为当前目录下的 fbdata.afdo。
（[...] 中针对-fauto-profile 的优化列表更长。）
【问题讨论】：
我通过一条我什至不记得的路径偶然发现了这个线程，并且在我前进的过程中正在学习这些东西。但如果我能从中学到一些东西，我不喜欢看到一个没有答案的问题！所以我开始阅读了。
正如 GCC 所说，这两种都是应用反馈导向优化的模式。通过运行程序并分析它做了什么、它是如何做的、它在哪些功能上花费了多长时间等等 - 我们可以从结果中促进额外的、定向优化数据。分析器的结果“前馈”给优化器。接下来，大概，您可以获取配置文件优化的二进制文件和配置文件 that，然后编译另一个 FDO 版本，依此类推......因此 feedback 部分名字。
真正的答案，即这两个开关之间的区别，并没有很清楚地记录在案，但如果我们需要进一步观察，它是可用的。
首先，您对-fprofile-use 的引用仅真正声明它需要-fprofile-generate，这是一个没有很好记录的选项：来自-use 的参考只是告诉您阅读您已经打开的页面，在所有情况下，-generate 仅被提及但从未定义。有用！ 但是！我们可以参考这个问题的答案：How to use profile guided optimizations in g++?
正如该答案所述，此处有问题的 GCC 文档温和地表明...-fprofile-generate 导致 instrumentation 被添加到输出二进制文件中.正如该页面所概述的那样，已检测的可执行文件添加了一些内容，以便在其运行时进行额外的检查或洞察。
（我知道的另一种检测形式 - 也是我使用过的一种 - 是编译器附加库 UBSan，我通过 GCC's -fsanitize=undefined option 使用它。这会在运行时捕获一些未定义的行为。使用 GCC揭示了 UB，否则我可能需要很长时间才能找到 - 这让我想知道我的程序是如何运行的！Clang can use this library too，也许还有其他编译器。）
相比之下，-fauto-profile 不同。您引用的概要中暗示了关键区别（如果不是很清楚）：
path是包含 AutoFDO 配置文件信息的文件的名称。
此模式使用 AutoFDO 处理分析和后续优化。谷歌我们去：AutoFDO 前几行并没有尽可能简洁地解释这一点，我认为最好的总结被埋在页面的很远的地方：
AutoFDO [
-fauto-profile] 和 FDO [-fprofile-use] 之间的主要区别在于 AutoFDO 配置文件是在优化的二进制文件而不是检测的二进制文件上。这使得它在处理克隆函数时非常不同。
它是如何做到的？ -fauto-profile 要求您提供由 Linux 内核的分析器 Perf 写入并转换为 AutoFDO 格式的分析文件。 Perf 不是添加工具，而是使用 CPU 的硬件特性和操作系统的内核级特性来分析程序运行时的各种统计信息：
perf功能强大：它可以检测 CPU 性能计数器、跟踪点、kprobes 和 uprobes（动态跟踪）。它能够进行轻量级分析。 [...] 性能计数器是 CPU 硬件寄存器，用于计算硬件事件，例如执行的指令、遭受的缓存未命中或错误预测的分支。它们构成了分析应用程序以跟踪动态控制流和识别热点的基础。
因此，它可以分析优化程序，而不是检测程序。我们可以合理地假设这更能代表您的程序在现实世界中的反应 - 因此可以促进收集更有用的分析数据并因此应用更有效的优化。
这里总结了如何将所有这些联系在一起并让-fauto-profile 对您的程序执行某些操作的示例：Feedback directed optimization with GCC and Perf
（也许现在我学会了所有这些，总有一天我会尝试这些选项！）
【讨论】：
underscore_d 深入洞察差异。
这是我的看法。
通过最初使用-fprofile-generate 编译来执行内部分析，它将分析器集成到二进制文件中以运行性能数据收集。执行二进制文件 10 分钟或任何您认为足以让分析器记录的活动的时间。如果它是多线程应用程序，请使用-fprofile-use 和-fprofile-correction 重新编译。内部分析器运行会导致显着的性能下降（在我的情况下为 25%），这并不能反映现实世界的非分析器包含的二进制行为，因此可能会导致分析的准确性降低，但如果运行分析器时的所有活动都启用了二进制缩放性能损失，我想应该没关系。
或者，您可以使用特定于您的内核（可能还需要构建内核以支持分析、跟踪等）的 perf 工具（更容易出错和努力）来创建分析数据。这可以被认为是外部分析，并且在分析时对应用程序性能的影响可以忽略不计。您在正常编译的二进制文件上运行它。我找不到任何比较这两者的研究。
perf record -e br_inst_retired:near_taken -b -o perf.data *your_program.unstripped -program -parameters*
然后在不剥离二进制文件的情况下，将分析数据转换为 GCC 可以理解的内容...
create_gcov --binary=your_program.unstripped --profile=perf.data --gcov=profile.afdo
然后使用-fauto-profile 重新编译应用程序。已知存在 Perf 和 AutoFDO/create_gcov 版本特定问题。我参考了https://blog.wnohang.net/index.php/2015/04/29/feedback-directed-optimization-with-gcc-and-perf/ 以获取有关此替代分析方法的详细信息。
-fprofile-use 和 -fauto-profile 默认情况下都启用了许多优化选项，在我的情况下，我知道不需要的 -funroll-loops 会对我的应用程序的性能产生负面影响。如果您是迂腐类型，您可以通过在编译标志中包含禁用对应项来测试选项组合，在我的情况下为 -fno-unroll-loops。
在剥离二进制文件后对我的程序使用内部分析，它减少了 25% 的大小（与原始的非分析器剥离的二进制文件相比）但是我只观察到低于百分位的性能提升和之前报告的工作输出波动程序日志（它是一个加密货币矿工）更加不稳定，而不是像原来那样在哈希率的高峰和低谷之间逐渐上升和下降。
总体而言，在黑暗中刺伤。
【讨论】：