是否有理由不使用链接时优化 (LTO)？

Question

GCC、MSVC、LLVM 和可能的其他工具链支持链接时间（整个程序）优化，以允许优化编译单元之间的调用。

编译生产软件时是否有理由不启用此选项？

原文由 Honza 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

我假设 “生产软件” 是指您运送给客户/投入生产的软件。 为什么不总是使用编译器优化？ （ Mankarse 亲切地指出）主要适用于您想要调试代码的情况（因此该软件仍处于开发阶段 - 未投入生产）。

自从我写这个答案以来已经过去了 6 年，需要更新。早在 2014 年，问题是：

• 链接时间优化偶尔会引入 细微的错误，例如 内核链接时间优化。我认为到 2020 年这不再是一个问题。防范此类编译器和链接器错误：进行适当的测试以检查您即将发布的软件的正确性。
• 增加编译时间。有人声称这种情况自 2014 年以来已显着改善，例如得益于 纤细的物体。
• 大内存使用。 这篇文章 声称，由于分区，近年来情况已大大改善。

从 2020 年开始，我将尝试在我的任何项目中默认使用 LTO。

原文由 Ali 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 2

LTO 还可以揭示代码签名算法中的边缘情况错误。考虑基于对某个对象或模块的 TEXT 部分的某些期望的代码签名算法。现在 LTO 优化了 TEXT 部分，或者以代码签名算法无法处理的方式将内容内联到其中。最坏的情况是，它只影响一个特定的分配管道，而不影响另一个，因为每个管道上使用的加密算法存在细微差别。祝你好运，弄清楚为什么应用程序从管道 A 而不是 B 分发时无法启动。

原文由 scaly 发布，翻译遵循 CC BY-SA 4.0 许可协议