LTO 中的优化是否与正常编译中的相同？答案

【问题标题】：Are the optimizations done in LTO the same as in normal compilation?LTO 中的优化是否与正常编译中的相同？
【发布时间】：2015-08-19 16:05:18
【问题描述】：

在编译翻译单元时，编译器会进行大量优化 - 内联、常量折叠/传播、别名分析、循环展开、死代码消除以及许多我从未听说过的其他优化。在多个翻译单元之间使用 LTO/LTCG/WPO 时是否全部完成，或者只是完成了其中的一个子集（或变体）（我听说过内联）？如果没有完成所有优化，我会考虑统一构建优于 LTO（或者当有超过 1 个统一源文件时可能同时使用它们）。

我的猜测是它不一样（统一构建具有完整的优化集），而且它在编译器之间变化很大。

每个编译器的 lto 文档并没有准确回答这个问题（或者我无法理解它）。

由于 lto 涉及将中间表示保存在目标文件中，理论上 LTO 可以进行所有优化......对吗？

请注意，我不是在询问构建速度 - 这是一个单独的问题。

编辑：我最感兴趣的是 gcc/llvm。

【问题讨论】：

就像您自己说的那样，编译器之间的差异可能很大。同时回答 GCC 和 LLVM 可能是可行的，但除此之外它太宽泛了。请缩小范围。
@BЈовић 链接时优化（或链接时代码生成或整个程序优化）
这取决于编译器和目标。例如，DSP 可以通过将一些代码放在内存的第一个块中来提高性能，这通常具有更快的访问速度。

标签： c++ optimization compiler-construction g++ llvm

【解决方案1】：

如果您查看您找到的 gcc 文档：

-flto[=n]

此选项运行标准链接时间优化器。当使用源代码调用时，它会生成 GIMPLE（GCC 的内部表示之一）并将其写入目标文件中的特殊 ELF 部分。当目标文件链接在一起时，所有的函数体都会从这些 ELF 部分中读取并实例化，就好像它们是同一个翻译单元的一部分一样。

要使用链接时优化器，应在编译时和最终链接期间指定 -flto 和优化选项。例如：

          gcc -c -O2 -flto foo.c
          gcc -c -O2 -flto bar.c
          gcc -o myprog -flto -O2 foo.o bar.o

对 GCC 的前两次调用将 GIMPLE 的字节码表示保存到 foo.o 和 bar.o 内的特殊 ELF 部分中。最后的调用从 foo.o 和 bar.o 中读取 GIMPLE 字节码，将这两个文件合并为一个内部映像，并像往常一样编译结果。由于 foo.o 和 bar.o 都合并到一个图像中，这会导致 GCC 中的所有过程间分析和优化在这两个文件中工作，就好像它们是一个文件一样。这意味着，例如，内联器能够将 bar.o 中的函数内联到 foo.o 中的函数中，反之亦然。

正如文档所述，是的，全部！优化就像程序在单个文件中编译一样。这也可以通过-fwhole-program 来完成，以获得“相同”的优化结果。

如果你编译这个非常简单的例子：

f1.cpp:

int f1() { return 10; }

f2.cpp:

int f2(int i) { return 2*i; }

main.cpp:

int main()
{   
    int res=f1();
    res=f2(res);
    res++;

    return res;
}

我得到了汇编输出：

00000000004005e0 <main>:
  4005e0:   b8 15 00 00 00          mov    $0x15,%eax
  4005e5:   c3                      retq   
  4005e6:   66 2e 0f 1f 84 00 00    nopw   %cs:0x0(%rax,%rax,1)
  4005ed:   00 00 00

所有代码都按预期内联。

我的经验是，实际的 gcc 使用 lto 进行优化，就像在单个文件中编译一样。在非常罕见的情况下，我在使用 lto 时得到了 ICE。但是在实际的 5.2.0 版本中，我再也没有看到任何 ICE。

[ICE]-> 内部编译器错误

【讨论】：