什么时候我可以放心地用-O3编译程序？

我见过很多人抱怨-O3 option:

• GCC：程序无法使用编译选项-O3
• 浮点问题由 David Hammen 提供

我查看了 GCC 的手册：

   -O3    Optimize yet more.  -O3 turns on all optimizations
          specified   by   -O2   and   also   turns  on  the
          -finline-functions and -frename-registers options.

我还确认了代码，以确保两个选项是其中包含的唯一两个优化-O3 on:

if (optimize >= 3){
    flag_inline_functions = 1;
    flag_rename_registers = 1;
}

对于这两个优化：

• -finline-functions在某些情况下（主要是 C++）很有用，因为它允许我们使用 -finline-limit 定义内联函数的大小（默认为 600）。设置高内联限制时，编译器可能会报告内存不足的错误。
• -frename-registers尝试通过使用寄存器分配后剩余的寄存器来避免调度代码中的错误依赖关系。这种优化最有利于具有大量寄存器的处理器。

对于内联函数来说，虽然可以减少函数调用次数，但是可能会导致二进制文件很大，所以-finline-functions可能会引入严重的缓存惩罚并且变得比 -O2 更慢。我认为缓存惩罚不仅取决于程序本身。

对于重命名寄存器，我认为它不会对 x86 这样的 cisc 架构产生任何积极影响。

我的问题有 2.5 个部分：

1. 我是否可以声称使用 -O3 选项程序是否可以运行得更快取决于底层平台/架构？ [已回答]

   EDIT:

   第 1 部分已被确认为真实的。 David Hammen 还声称，我们应该非常小心优化和浮点运算如何在具有扩展精度浮点寄存器（如 Intel 和 AMD）的机器上交互。

2. 什么时候才能放心使用-O3 option?我认为这两个优化尤其是重命名寄存器可能会导致与 -O0/O2 不同的行为。我看到一些程序编译为-O3在执行过程中崩溃了，它是确定性的吗？如果我运行一个可执行文件一次而没有任何崩溃，这是否意味着它可以安全使用-O3?

   编辑：确定性与优化无关，它是一个多线程问题。但是对于多线程程序来说，使用起来并不安全-O3当我们运行一次可执行文件而没有错误时。大卫·哈曼表明-O3浮点运算的优化可能违反比较的严格弱排序标准。我们在使用的时候还有什么需要注意的地方吗？-O3 option?

3. 如果第一个问题的答案是“是”，那么当我更改目标平台或在具有不同机器的分布式系统中时，我可能需要在-O3 and -O2。有没有通用的方法来决定我是否可以获得性能改进-O3？比如更多的寄存器、短的内联函数等。【已解答】

   编辑：第三部分已被 Louen 回答为“平台的多样性使得对这个问题的一般推理变得不可能”在评估性能增益时-O3，我们必须同时尝试两者并对我们的代码进行基准测试，看看哪个更快。

2. 我看到一些程序在使用 -O3 编译时崩溃了，它是确定性的吗？

如果程序是单线程的，则程序使用的所有算法都是确定性的，并且如果运行之间的输入相同，则可以。如果其中任何一个条件不成立，答案是“不一定”。

如果您在不使用 -O3 的情况下进行编译，则同样适用。

如果我运行一次可执行文件而没有任何崩溃，是否意味着使用 -O3 是安全的？

当然不是。同样，如果您在不使用 -O3 的情况下进行编译，则同样适用。仅仅因为您的应用程序运行一次并不意味着它在所有情况下都会成功运行。这就是测试成为难题的部分原因。

在浮点寄存器比双精度精度更高的机器上，浮点运算可能会导致奇怪的行为。例如，

void add (double a, double b, double & result) {
   double temp = a + b;
   result = temp;
   if (result != temp) {
      throw FunkyAdditionError (temp);
   }
}

编译一个使用它的程序add功能未优化，您可能永远不会看到任何FunkyAdditionError例外情况。编译优化和某些输入将突然开始导致这些异常。问题是，通过优化，编译器将使temp注册同时result，作为参考，不会被编译到寄存器中。添加一个inline限定符和当你的编译器编译时这些异常可能会消失-O3因为现在result也可以是一个寄存器。浮点运算的优化可能是一个棘手的话题。

最后，让我们看一下其中一个案例，当使用 -O3 编译程序时，晚上事情确实发生了碰撞，GCC：程序无法使用编译选项 -O3。该问题仅出现在 -O3 中，因为编译器可能内联了distance函数，但将其中一个（但不是两个）结果保留在扩展精度浮点寄存器中。通过此优化，某些点p1 and p2可以导致两者p1<p2 and p2<p1评价为true。这违反了比较函数的严格弱排序标准。

您需要非常小心优化和浮点操作如何在具有扩展精度浮点寄存器的机器（例如 Intel 和 AMD）上交互。