在GCC中使用-O3有什么缺点吗？

Question

我已经在各种语言中担任了13年的软件工程师，尽管我现在正在进入C和后来的C ++。 当我正在学习C时，我正在使用GCC编译器来编译我的程序，我想知道是否有使用-O3或其他优化标志的问题。 如果没有测试编译的代码，或者在交叉编译期间，我的软件可能会破坏我无法捕获的方式，我可能会无意中混淆了某个不同的平台。

在我盲目地打开这些选项之前，我想知道我能期待什么。 此外，由于-Ofast打开了不符合标准的标志，我倾向于不使用它。 在我的假设中，我是否正确--Ofast很可能会产生“副作用？”

在发布此问题之前，我已经浏览了https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html 。

Answer 1

-O3的唯一缺点应该是无法在调试器中遵循代码。

使用-Ofast会影响一些浮点运算导致舍入错误，但除非您运行特定的长链浮点计算，否则您不太可能注意到。

破坏的代码（带有错误指针的代码或具有未定义行为的语句）可能在不同的优化级别上表现不同 - 许多程序员的第一反应是责怪编译器 - 启用所有警告并修复它们通常会有所帮助。

Answer 2

重要的是要记住几乎所有编译器优化都是启发式的 。 换句话说，“optmization”只是试图使你的程序更“理想”，但它可能会产生相反的效果。 仅仅因为-O3应该优于-O2 ，并且-O2应该优于-O1 - 这并不意味着实际上它总是如何工作。

有时，与使用-O2或-O1生成的版本相比， -O3启用的“优化”实际上可能会降低程序速度。 您应该尝试不同级别的优化，以查看哪种方法最适合您的特定代码。 如果您真的想要对其进行微调，您甚至可以打开和关闭各个选项。

所以简而言之，使用-O3可能会有缺点。 我个人观察到我写的很多东西在使用-O2比使用-O3更好 - 但这确实是程序特定的。

---

仅供参考，这是另一个SO问题，它询问为什么-O2为特定程序提供比-O3更好的结果： gcc优化标志-O3使代码慢于-O2

Answer 3

由于-O3开始移动代码以优化它，在某些情况下，您可能会看到结果不同或中断。

如果使用-O3测试代码的正确性并找到无法调试的问题，建议切换到-O0以查看是否获得相同的行为。

Answer 4

“我想知道我能期待什么”

我在嵌入式系统中使用C ++（主要是vxWorks上的GCC）超过20年。 我非常尊重编译器编写者。

---

相信你的编译器：恕我直言，-O3从来没有破坏任何代码......但有时会发现有趣的编码错误。

---

选择：参赛队必须选择是否要“寄给你考什么，并测试你的船是什么”，无论-O1或-O3选择。 我与之合作的团队一直致力于使用-O3进行发货和测试。

---

单步可以是不合作的：在个人实践层面，当使用-O3代码时，我通常会“放弃”gdb单步。 我更多地使用了断点，并且编码选择略有不同，使自动变量（堆栈数据）和类数据更“可见”。 （你可以使gdb命令'p'成为你不方便的朋友）。

---

单步是必要的：请注意，即使我们使用-O3“测试并运送”，我们几乎只使用-O1代码进行调试。

---

调试是必要的：调试-01之间的权衡，但测试和运输-O3是切换两个可执行文件所需的额外重新编译。 在-O1中保存以探索，识别和修复代码错误的时间必须构成2次重建（到-01并返回到-O3）。

---

回归测试自动化：我想说-O3的系统测试（也称为集成测试或回归测试）必须提升一个档次，但我无法真正描述它......或许我应该推荐测试自动化水平更高（每一个REGRESSION TESTs！）。 但我不确定。 回归测试的自动化级别可能更多地与团队规模相关，而不是与绩效水平相关。

---

“成功”的嵌入式系统可以做两件事。 它满足要求。 并且，我认为更重要的是，在所有人类可见的行为中，它就像一个轻载的桌面。 对于任何动作（按钮按压，电缆断开，测试设备引起的误差，或甚至低状态的灯光变化），结果都没有人类可察觉的延迟。 -O3有帮助。 一个成功的系统可以完成......我已经看过了。