Por que o compilador Rust não otimiza o código assumindo que duas referências mutáveis ​​não podem usar o alias?

Até onde eu sei, o aliasing de referência / ponteiro pode prejudicar a capacidade do compilador de gerar código otimizado, pois eles devem garantir que o binário gerado se comporte corretamente no caso em que as duas referências / ponteiros realmente sejam alias. Por exemplo, no código C a seguir,

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

quando compilado clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)com a -O3bandeira, emite

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

Aqui, o código é armazenado novamente (%rdi)duas vezes em case int *ae int *balias.

Quando dizemos explicitamente ao compilador que esses dois ponteiros não podem usar o alias da restrictpalavra-chave:

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

Então o Clang emitirá uma versão mais otimizada do código binário:

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

Como o Rust garante (exceto no código não seguro) que duas referências mutáveis ​​não possam usar o alias, eu pensaria que o compilador deveria poder emitir a versão mais otimizada do código.

Quando eu testo com o código abaixo e o compilo rustc 1.35.0com -C opt-level=3 --emit obj,

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

gera:

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

Isso não tira proveito da garantia que ae bnão pode ser um alias.

Isso ocorre porque o atual compilador Rust ainda está em desenvolvimento e ainda não incorporou a análise de alias para fazer a otimização?

Isso ocorre porque ainda existe uma chance ae bpoderia, mesmo em Rust seguro?

Rust originalmente fez habilitar do LLVM noaliasatributo, mas este código miscompiled causado . Quando todas as versões suportadas do LLVM não compactarem mais o código, ele será reativado .

Se você adicionar -Zmutable-noalias=yesàs opções do compilador, obterá o assembly esperado:

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

Simplificando, Rust colocou o equivalente à restrictpalavra-chave de C em todos os lugares , muito mais prevalente do que qualquer programa C usual. Isso exercitou casos de canto do LLVM mais do que era capaz de lidar corretamente. Acontece que os programadores de C e C ++ simplesmente não usam restrictcom tanta frequência quanto &muté usado no Rust.

Isso aconteceu várias vezes .

• Rust 1.0 a 1.7 - noaliasativado
• Rust 1.8 a 1.27 - noaliasdesativado
• Ferrugem 1,28 a 1,29 - noaliasativado
• Ferrugem 1,30 a ??? - noaliasdesativado

Problemas de ferrugem relacionados

• Caso atual

  • Geração de código incorreta para nalgebra's Matrix :: swap_rows () # 54462
  • Reative as anotações de noalias por padrão, uma vez que o LLVM não os compile mais incorretamente # 54878

• Caso anterior

  • Solução alternativa do bug do otimizador LLVM ao não marcar e alterar ponteiros como noalias # 31545
  • Marque e mude os ponteiros como noalias, uma vez que o LLVM não os compile mais # 31681

• De outros

  • use os metadados de noalias com escopo definido no LLVM # 16515
  • Otimização perdida: as referências dos ponteiros não são tratadas como noalias # 38941
  • noalias não é suficiente # 53105
  • noalias mutáveis: reativar permanentemente, apenas para pânico = abortar ou estabilizar sinalizador? # 45029