弥合差距：Rust 与 C/C++ 之间的跨语言 LTO

• Rust 由于没有语言运行时，并且具有底层访问能力，几乎可以无缝地集成到现有的 C/C++ 代码库中，
• 而 LLVM 作为一个语言无关的底层基础，提供了一个共同基础，在这里特定代码段所用到的源语言不再重要。

• 从技术角度来看，它允许代码库在不考虑实现语言边界的情况下进行优化，使得重要的优化（例如函数内联）能够跨编译单元执行，即使例如其中一个编译单元是用 Rust 编写的，而另一个是用 C++ 编写的。
• 从心理角度来看，这同样重要，它有助于减轻许多注重性能的开发人员在处理在不同源语言中实现的函数之间频繁跳转的软件时，可能会产生的效率低下感。

背景 - LLVM 编译管道的鸟瞰图

1. 编译器前端为每个编译单元生成一个 LLVM 位码模块 (.bc)。在 C 和 C++ 中，每个源文件将生成一个编译单元。在 Rust 中，每个包至少会被翻译成一个编译单元。
   

   
       .c --clang--> .bc
   
       .c --clang--> .bc
   
   
       .rs --+
             |
       .rs --+--rustc--> .bc
             |
       .rs --+
   
   

2. 在下一步中，LLVM 的优化管道将独立地优化每个 LLVM 模块。

   
       .c --clang--> .bc --LLVM--> .bc (opt)
   
       .c --clang--> .bc --LLVM--> .bc (opt)
   
   
       .rs --+
             |
       .rs --+--rustc--> .bc --LLVM--> .bc (opt)
             |
       .rs --+
   
   

3. 然后，LLVM 将每个模块降低为机器码，这样我们就能为每个模块获得一个目标文件。

   
       .c --clang--> .bc --LLVM--> .bc (opt) --LLVM--> .o
   
       .c --clang--> .bc --LLVM--> .bc (opt) --LLVM--> .o
   
   
       .rs --+
             |
       .rs --+--rustc--> .bc --LLVM--> .bc (opt) --LLVM--> .o
             |
       .rs --+
   
   

4. 最后，链接器将接收目标文件的集合，并将它们链接成一个二进制文件。

   
       .c --clang--> .bc --LLVM--> .bc (opt) --LLVM--> .o ------+
                                                                |
       .c --clang--> .bc --LLVM--> .bc (opt) --LLVM--> .o ------+
                                                                |
                                                                +--ld--> bin
       .rs --+                                                  |
             |                                                  |
       .rs --+--rustc--> .bc --LLVM--> .bc (opt) --LLVM--> .o --+
             |
       .rs --+
   
   

LLVM 中的链接时优化

• 编译器将每个编译单元翻译成 LLVM 位码（即跳过降低为机器码的步骤），
   
• 链接器通过 LLVM 链接器插件知道如何像读取常规目标文件一样读取 LLVM 位码模块，以及
   
• 链接器再次通过 LLVM 链接器插件合并它遇到的所有位码模块，然后在进行实际链接之前运行 LLVM 优化过程。

    .c --clang--> .bc --LLVM--> .bc (opt) ------------------+ - - +
                                                            |     |
    .c --clang--> .bc --LLVM--> .bc (opt) ------------------+ - - +
                                                            |     |
                                                            +-ld+LLVM--> bin
    .rs --+                                                 |
          |                                                 |
    .rs --+--rustc--> .bc --LLVM--> .bc (opt) --LLVM--> .o -+
          |
    .rs --+

跨语言链接时优化

    .c --clang--> .bc --LLVM--> .bc (opt) ---------+
                                                   |
    .c --clang--> .bc --LLVM--> .bc (opt) ---------+
                                                   |
                                                   +-ld+LLVM--> bin
    .rs --+                                        |
          |                                        |
    .rs --+--rustc--> .bc --LLVM--> .bc (opt) -----+
          |
    .rs --+

• Rust 编译器和 Clang 都是基于 LLVM 的，但它们可能使用的是不同版本的 LLVM。由于 Rust 的 LLVM 版本通常与特定的 LLVM 版本不匹配，而是 LLVM 存储库中的任意修订版本，因此情况变得更加复杂。我们了解到，所有参与的 LLVM 版本必须非常接近，才能使一切正常运行。Rust 编译器的文档现在提供了有关 Rust 和 Clang 不同版本之间的兼容性表。
   
• Rust 编译器默认情况下对同一个包的所有编译单元执行一种特殊的 LTO 形式，称为ThinLTO，然后将它们传递给链接器。然而，我们很快就发现，当尝试对已经过 ThinLTO 过程的模块执行另一轮 ThinLTO 时，LLVM 链接器插件会发生段错误。我们认为，没问题，我们指示 Rust 编译器在为跨语言情况编译时禁用它自己的 ThinLTO 过程，事实的确如此，一切都很好 - 直到几周后，即使 ThinLTO 仍然被禁用，段错误又神秘地返回了。
  
  我们注意到，问题只出现在一个特定的、可能是无害的设置中：同样需要进行两轮 LTO，这次第一轮是在 rustc 中的常规 LTO 过程，然后将它的输出输入到链接器插件中的 ThinLTO 中。这种设置虽然计算量大，但很受欢迎，因为它可以生成更快的代码，并在 Rust 端允许进行更好的死代码消除。理论上，它应该工作正常。然而，不知何故，rustc 生成了符号名称，这些符号名称显然已经过 ThinLTO 的混淆处理，即使我们多次检查确认 ThinLTO 已针对 Rust 被禁用。当问题持续存在，而我们逐渐耗尽了如何进一步调试这个问题的想法时，我们开始质疑自己对 LLVM 内部工作原理的理解。
  
  当我们发现 Rust 的预编译标准库仍然会启用 ThinLTO 时，您可以想象我们头上出现了一个象征性的灯泡，无论我们对测试使用什么编译器设置，都是如此。标准库（包括它的 LLVM 位码表示）是在 Rust 的二进制分发版中作为一部分编译的，因此它总是使用 Rust 的构建服务器中的设置进行编译。然后，我们在 rustc 中的本地完整 LTO 过程会将这个有问题的位码拉入输出模块中，进而导致链接器插件再次崩溃。从那时起，ThinLTO 默认情况下就关闭了 libstd。
   
• 在进行上述修复之后，我们成功地使用跨语言 LTO 编译了整个 Firefox。不幸的是，我们发现没有真正进行跨语言优化。Clang 和 rustc 都在生成 LLVM 位码，而 LLD 生成了功能完备的 Firefox 二进制文件，但当查看机器码时，即使是简单的函数也没有跨语言边界内联。经过数天的调试（不幸的是，当时我们没有意识到LLVM 的优化备注），事实证明，Clang 在所有函数上都发出一个 target-cpu 属性，而 rustc 没有，这导致 LLVM 拒绝内联机会。
  
  为了防止该功能因类似原因在将来默默地倒退，我们在扩展 Rust 编译器的测试框架和 CI 上花费了大量的精力。它现在能够编译并运行一个兼容版本的 Clang，并使用它来执行跨语言 LTO 的端到端测试，确保小函数确实会跨语言边界内联。

使用跨语言 LTO：一个最小的示例

    # Compile the Rust static library, called "xyz"
    rustc --crate-type=staticlib -O -C linker-plugin-lto -o libxyz.a lib.rs

    # Compile the C code with "-flto"
    clang -flto -c -O2 main.c

    # Link everything
    clang -flto -O2 main.o -L . -lxyz

结论

致谢