c++ - 在分析代码时，我应该使用匹配的 (gcc) 编译器优化标志吗？

Question

我正在使用 -O3在编译代码时，现在我需要分析它。对于分析，我遇到了两个主要选择:valgrind --tool=callgrind和 gprof .

Valgrind (callgrind) 文档状态:

As with Cachegrind, you probably want to compile with debugging info (the -g option) and with optimization turned on.

但是，在 C++ optimization book由 Agner Fog 撰写，我已阅读以下内容:

Many optimization options are incompatible with debugging. A debugger can execute a code one line at a time and show the values of all variables. Obviously, this is not possible when parts of the code have been reordered, inlined, or optimized away. It is common to make two versions of a program executable: a debug version with full debugging support which is used during program development, and a release version with all relevant optimization options turned on. Most IDE's (Integrated Development Environments) have facilities for making a debug version and a release version of object files and executables. Make sure to distinguish these two versions and turn off debugging and profiling support in the optimized version of the executable.

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

-ggdb -DFULLDEBUG

我不会导致此选项与 -O3 优化标志冲突吗？到目前为止，我已经阅读了这两个选项，这对我来说毫无意义。

如果我使用 say -O3 优化标志，我可以使用以下方法编译带有附加分析信息的代码:

-pg

并且仍然使用 valgrind 对其进行分析？

剖析用

编译的代码是否有意义

-ggdb -DFULLDEBUG -O0

旗帜？这看起来很愚蠢 - 不内联函数和展开循环可能会转移代码中的瓶颈，因此这应该仅用于开发，以使代码真正正确地做事。

用一个优化标志编译代码，然后分析用另一个优化标志编译的代码是否有意义？

Answer 1

你为什么要分析？只是为了获得测量值或寻找加速？

您应该只分析优化代码的常识是基于假设代码开始时几乎是最优的，如果有显着的加速，但事实并非如此。

您应该将发现的加速比视为错误。很多人用this method这样做。

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