在分析代码时，我应该使用匹配（gcc）编译器优化标志吗？

Question

我在编译代码时使用-O3 ，现在我需要对其进行分析。 对于分析，我有两个主要选择： valgrind --tool = callgrind和gprof 。

Valgrind（callgrind）文档声明：

与Cachegrind一样，您可能希望使用调试信息（-g选项）进行编译并启用优化。

但是，在Agner Fog的C ++优化书中 ，我读过以下内容：

许多优化选项与调试不兼容。 调试器可以一次执行一行代码并显示所有变量的值。 显然，当部分代码被重新排序，内联或优化时，这是不可能的。 通常可以使程序的两个版本可执行：在程序开发期间使用的具有完全调试支持的调试版本，以及启用了所有相关优化选项的发布版本。 大多数IDE（集成开发环境）都具有制作调试版本和目标文件和可执行文件的发行版本的工具。 确保区分这两个版本并关闭可执行文件的优化版本中的调试和分析支持。

这似乎与callgrind指令冲突，以使用调试信息标志-g编译代码。 如果我按以下方式启用调试：

-ggdb -DFULLDEBUG

我不会导致此选项与-O3优化标志冲突吗？ 在我到目前为止所阅读的内容之后，使用这两个选项对我来说毫无意义。

如果我使用说-O3优化标志，我可以使用以下命令编译带有其他分析信息的代码：

-pg

仍然用valgrind描述它？

配置编译的代码是否有意义

-ggdb -DFULLDEBUG -O0

标志？ 这看起来很愚蠢 - 不是内联函数和展开循环可能会改变代码中的瓶颈，所以这应该仅用于开发，以使代码实际上正确地执行 。

用一个优化标志编译代码并用另一个优化标志编译代码是否有意义？

Answer 1

你为什么要剖析？ 只是为了测量或找到加速？

您应该只分析优化代码的常识是基于假设代码几乎是最佳的开始，如果有显着的加速，则不是。

您应该将加速的发现视为错误。 许多人使用这种方法 。

在你删除了不必要的计算后，如果你仍然有紧张的CPU循环，即你没有把所有的时间花在系统或库或优化器没有看到的I / O例程上，那么打开-O3，然后让它做它的魔力。