从源代码构建编译器会带来更好的优化吗？答案

【问题标题】：Does building the compiler from source result in better optimization?从源代码构建编译器会带来更好的优化吗？
【发布时间】：2014-02-24 20:59:36
【问题描述】：

考虑这个简单的案例场景：

我为我的通用操作系统（不是 Windows）下载了 C++ 编译器的预构建二进制文件（比如 CLang 或 GCC 或其他任何东西）。我编译了我的代码，其中包含一些计算量很大的数学计算，带有优化标志-O3，我的执行时间为T1。

在一次不同的尝试中，这次我下载源代码并在我的通用机器上自己构建编译器，而不是使用预构建的二进制文件。我用相同的优化标志编译相同的代码，达到执行时间T2?

T2 < T1 会不会大体相同？

换句话说，执行时间是否独立于编译器的构建方式？

【问题讨论】：

您是否怀疑预构建二进制文件的构建方式遗漏了它可以做的一些优化？如果有，为什么？
我只希望编译时间会发生变化。
@Wooble，没错！我曾经/正在使用 GCC，而我在另一个实验室的同事是 CLang 用户。我们所做的在本质上是相似的，然而，并不完全相同。他们告诉他们使用 clang 取得了更好的结果，但是，当我切换到 clang 时，我意识到我的 GCC 仍然更好。问他们时，他们都说他们编译了clang，而我使用的是预建的。我只是想知道这是否相关。
很高兴知道投反对票的原因...

标签： c++ optimization compiler-construction

【解决方案1】：

编译器对代码的优化是编译器行为的结果，而不是编译器性能的结果。

只要编译器具有相同的行为设计，它就会产生完全相同的输出。

【讨论】：

更进一步，如果所有编译设置和环境都相同，不仅编译器的输出相同，生成的编译器二进制文件也将与预构建的完全相同那些（可能除了时间戳，如果有的话）。
这不是攻击，我只是想在接受答案之前澄清一切。您所说的是编译器的 no 属性是从机器（编译器构建在其上）获取的，并且会影响执行时间。这个说法是真的吗？
理论上可行，但极不可能。据我所知，我会说你的区别只是因为你在不同的机器上进行测试。
Excelsius 是对的，IIRC GCC 实际上在其引导安装过程中使用了这个属性。它编译自身两次，优化和不优化，并检查两个构建是否产生相同的结果。（优化后的 GCC 应该会在更短的时间内产生相同的结果）

【解决方案2】：

通常相同的编译器版本应该在相同的 C 或 C++ 代码输入的情况下生成相同的汇编代码。但是，当您运行编译器时，某些事情可能会进一步影响正在执行的代码。

发行版可能已从其他版本向后移植（甚至创建自己的）补丁。
现代编译器通常具有库依赖项（例如 cloog），这些依赖项在不同版本中可能具有不同的行为，导致编译器基于其他数据做出代码生成决策
这些库（在某些编译器版本中）在编译时可能是可选的（可能需要提供 --enable 开关来配置，或者 configure 尝试自动检测它们）。
像-march=native 这样的编译器开关将查看您编译的硬件并尝试进行相应的优化。
编译器优化器触发器的时间限制，本质上是在更好的机器上进行更好的优化；或相同的内存（我认为现代编译器中不再存在）

也就是说，即使是同一个汇编程序，在您和他们的机器上也可能执行不同的操作，例如因为一个是为 AMD 优化的，另一个是为英特尔优化的。

【讨论】：

【解决方案3】：

在我看来，理论上，编译速度可以更快，因为你可以说“编译器编译器”，“请针对我的电脑，你可以使用我电脑的处理器自己的机器码来优化” .

但我认为编译器的优化不可能更快。为了让编译器的优化更快，我认为我们需要在编译器中加入一些新技术，而不仅仅是重新编译。

【讨论】：

【解决方案4】：

这取决于编译器的实现方式和您的平台，但答案很可能是“否”。

如果您的平台提供可以提高程序性能的特定功能，则编译器中的优化器可能使用该功能来生成更快的程序。仅当编译器编写者知道该功能并在优化器中为您的平台实施了特殊处理时，优化器才能这样做。如果是这种情况，检测可能会在优化器中动态完成，这意味着优化器的任何构建都可以检测平台并优化您的代码。只有如果由于某种原因必须在优化器的编译时进行检测，在您的平台上重新编译它可能会带来这种优势。但是如果存在这样一个更适合您的平台的构建，编译器供应商很可能已经为它提供了二进制文件。

因此，有了所有这些 if，当您在您的平台上重新编译编译器时，您的程序不太可能更快。但是，如果针对您的平台而不是通用二进制文件进行优化，编译器有可能会更快一些，从而缩短编译时间。

【讨论】：