使用-O3优化来编译GNU / Linux

据说，使用-O3gcc优化选项编译GNU工具和Linux内核会产生怪异和时髦的错误。是真的吗 有没有人尝试过或者仅仅是骗局？

它是在Gentoo中使用的，我没有发现任何异常。

-O3 有几个缺点：

1. 首先，它产生的代码通常比-O2或慢-Os。有时由于循环展开会产生更长的代码，而实际上由于糟糕的代码缓存性能而可能会变慢。
2. 据说它有时会产生错误的代码。这可能是由于优化错误或代码错误（例如忽略严格的别名）引起的。由于内核代码有时是并且有时必须是“智能”的，所以我会说某些内核开发人员可能会犯一些错误。当我用gcc 4.5编译内核时，我遇到了各种奇怪的问题，例如用户空间实用程序崩溃，当时它是稳定的。由于各种错误，我仍将gcc 4.4用于内核和一些选定的用户空间实用程序。可能同样适用-O3。
3. 我认为它不会为Linux内核带来太大好处。内核不执行繁重的计算，而是在某些地方进行了汇编优化。-O3标志不会改变上下文切换的成本或I / O的速度。我认为总性能提升不到<0.1％的东西是不值得的。

请注意，如果更改优化级别，则工具链中的大部分（尤其是glibc）将无法编译。在大多数理智的发行版中，构建系统都设置为忽略这些部分的-O首选项。

简而言之，某些基本库和OS功能取决于代码实际执行的内容，而不是在许多情况下会更快的代码。特别是-fgcse-after-reload（由-O3启用）可能会引起奇怪的问题。

在过去的10年中，我已经在-O3 -march=native全球范围内使用1000多个软件包运行了多个Gentoo系统，但尚未遇到任何-O3应该具有的神话般的稳定性问题。CPU密集型应用程序（例如数学/科学应用程序）的基准始终显示出-O3可以生成更快的代码，毕竟如果没有，那将毫无意义。对于大多数台式机应用程序CFLAGS来说，它们并不受IO的限制，因此无论如何都没什么大不了的，但是对于受CPU约束的服务器端而言，这却很重要。

-O3使用一些积极的优化方法，这些优化方法只有在有关寄存器使用，堆栈帧如何交互以及函数重入的某些假设为真时才是安全的，并且不能保证这些假设在某些代码（如内核）中正确，特别是当内联汇编为使用（因为它在内核及其驱动程序模块的某些非常底层的部分中）。

尽管您可以在大多数应用程序上使用-O3和其他优化旋钮（并且可以提高速度），但是我还是会犹豫是否要对内核本身或构建内核所需的工具链（编译器，binutils，等等。）。

考虑一下：raid和ext3子系统5％的性能提升值得系统崩溃或潜在的数据丢失和/或损坏吗？

调整要播放的Quake端口所需的所有旋钮或用于将DVD集合翻录为divx文件的音频/视频编解码器。您可能会看到一个改善。只是不要弄乱内核，除非您有时间浪费和承受损失的数据。