使用 -O3 优化编译 GNU/Linux

Question

据说用-O3gcc 优化选项编译 GNU 工具和 Linux 内核会产生奇怪和时髦的错误。这是真的吗？有没有人尝试过，还是只是一个骗局？

Answer 1

-O3 有几个缺点：

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

Answer 2

它在 Gentoo 中使用，我没有注意到任何异常。

Answer 3

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

简而言之，某些基本的库和操作系统功能取决于代码实际执行它所说的，而不是在许多情况下会更快。特别是 -fgcse-after-reload（由 -O3 启用）可能会导致奇怪的问题。

Answer 4

在过去的 10 年里，我一直在运行多个 Gentoo 系统，其中包含 1000 多个-O3 -march=native在全球范围内使用的软件包，但还没有遇到任何这些-O3本应存在的神秘稳定性问题。CPU 密集型应用程序（如数学/科学应用程序）的基准测试始终显示-O3可以生成更快的代码，毕竟如果不这样做，它将毫无意义。对于大多数桌面应用程序而言，CFLAGS它们并不重要，因为它们受 IO 限制，但对于受 CPU 限制的服务器端内容来说却很重要。

Answer 5

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