首页 > 解决方案 > 假设两个可变引用不能别名,为什么 Rust 编译器不优化代码?

问题描述

据我所知,引用/指针别名会阻碍编译器生成优化代码的能力,因为它们必须确保生成的二进制文件在两个引用/指针确实别名的情况下正确运行。例如,在下面的 C 代码中,

void adds(int  *a, int *b) {
    *a += *b;
    *a += *b;
}

clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)使用-O3标志编译时,它会发出

0000000000000000 <adds>:
   0:    8b 07                    mov    (%rdi),%eax
   2:    03 06                    add    (%rsi),%eax
   4:    89 07                    mov    %eax,(%rdi)  # The first time
   6:    03 06                    add    (%rsi),%eax
   8:    89 07                    mov    %eax,(%rdi)  # The second time
   a:    c3                       retq

在这里,代码存储回(%rdi)两次以防万一int *aint *b别名。

当我们明确告诉编译器这两个指针不能使用restrict关键字别名时:

void adds(int * restrict a, int * restrict b) {
    *a += *b;
    *a += *b;
}

然后 Clang 将发出更优化的二进制代码版本:

0000000000000000 <adds>:
   0:    8b 06                    mov    (%rsi),%eax
   2:    01 c0                    add    %eax,%eax
   4:    01 07                    add    %eax,(%rdi)
   6:    c3                       retq

由于 Rust 确保(在不安全的代码中除外)两个可变引用不能别名,我认为编译器应该能够发出更优化的代码版本。

rustc 1.35.0当我使用下面的代码进行测试并使用with 进行编译时-C opt-level=3 --emit obj

#![crate_type = "staticlib"]
#[no_mangle]
fn adds(a: &mut i32, b: &mut i32) {
    *a += *b;
    *a += *b;
}

它生成:

0000000000000000 <adds>:
   0:    8b 07                    mov    (%rdi),%eax
   2:    03 06                    add    (%rsi),%eax
   4:    89 07                    mov    %eax,(%rdi)
   6:    03 06                    add    (%rsi),%eax
   8:    89 07                    mov    %eax,(%rdi)
   a:    c3                       retq

这没有利用保证a并且b不能别名。

这是因为当前的 Rust 编译器仍在开发中,还没有结合别名分析来进行优化吗?

这是因为即使在安全的 Rust 中,仍然有可能a并且可以别名?b

标签: rustcompiler-optimizationllvm-codegen

解决方案


Rust 最初确实启用了 LLVM 的noalias属性,但这导致了错误编译的代码。当所有支持的 LLVM 版本不再错误编译代码时,它将被重新启用

如果添加-Zmutable-noalias=yes到编译器选项,您将获得预期的程序集:

adds:
        mov     eax, dword ptr [rsi]
        add     eax, eax
        add     dword ptr [rdi], eax
        ret

简单地说,Rust 把相当于 C 的restrict关键字放在了任何地方,比任何普通的 C 程序都流行得多。这使 LLVM 的极端情况超出了它能够正确处理的范围。事实证明,C 和 C++ 程序员根本不像在 Rust 中restrict那样频繁使用。&mut

这已经发生过多次了。

  • Rust 1.0 到 1.7 —noalias启用
  • Rust 1.8 到 1.27 —noalias禁用
  • Rust 1.28 到 1.29 —noalias启用
  • Rust 1.30 到 1.54 —noalias禁用
  • Rust 1.54 到 ??? —noalias根据编译器使用的 LLVM 版本有条件地启用

相关的 Rust 问题


推荐阅读