有没有理由不使用链接时间优化（LTO）的原因？ [英] Is there a reason why not to use link-time optimization (LTO)?

问题描述

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

GCC, MSVC, LLVM, and probably other toolchains have support for link-time (whole program) optimization to allow optimization of calls among compilation units.

为什么在编译生产软件时不启用此选项？

Is there a reason not to enable this option when compiling production software?

推荐答案

我认为通过生产软件 是指您交付给客户/投入生产的软件。 为什么不总是使用编译器优化？（ Mankarse ）通常适用于您要调试自己的情况代码（因此该软件仍处于开发阶段-尚未投入生产）。

I assume that by "production software" you mean software that you ship to the customers / goes into production. The answers at Why not always use compiler optimization? (kindly pointed out by Mankarse) mostly apply to situations in which you want to debug your code (so the software is still in the development phase -- not in production).

自我编写此答案以来已经过去了6年，因此必须进行更新。早在2014年，问题是：

6 years have passed since I wrote this answer, and an update is necessary. Back in 2014, the issues were:

• 链接时间优化偶尔会引入细微的错误，例如内核的链接时优化。我认为从2020年开始，这将不再是一个大问题。防范此类编译器和链接器错误：进行适当的测试，以检查将要发布的软件的正确性。


• 增加了编译时间 。有人声称，自2014年以来，情况有了明显改善，例如，这要归功于 slim对象。


• 大内存使用量。 这篇文章声称，近年来这种情况已大大改善，

• Link time optimization occasionally introduced subtle bugs, see for example Link-time optimization for the kernel. I assume this is less of an issue as of 2020. Safeguard against these kinds of compiler and linker bugs: Have appropriate tests to check the correctness of your software that you are about to ship.
• Increased compile time. There are claims that the situation has significantly improved since 2014, for example thanks to slim objects.
• Large memory usage. This post claims that the situation has drastically improved in recent years, thanks to partitioning.

截至2020年，我将尝试在所有项目上默认使用LTO。

As of 2020, I would try to use LTO by default on any of my projects.

这篇关于有没有理由不使用链接时间优化（LTO）的原因？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！