Dlaczego kompilator Rust nie optymalizuje kodu, zakładając, że dwa zmienne odwołania nie mogą aliasu?

O ile mi wiadomo, aliasing odniesień / wskaźników może utrudniać kompilatorowi generowanie zoptymalizowanego kodu, ponieważ muszą one zapewnić, że wygenerowany plik binarny zachowuje się poprawnie w przypadku, gdy dwa odniesienia / wskaźniki faktycznie są aliasami. Na przykład w poniższym kodzie C

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

po skompilowaniu clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)z -O3flagą, emituje

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

Tutaj kod przechowuje z powrotem do (%rdi)dwukrotności w przypadku int *ai int *baliasu.

Gdy wyraźnie informujemy kompilator, że te dwa wskaźniki nie mogą aliasu ze restrictsłowem kluczowym:

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

Następnie Clang wyemituje bardziej zoptymalizowaną wersję kodu binarnego:

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

Ponieważ Rust upewnia się (z wyjątkiem niebezpiecznego kodu), że dwa zmienne odwołania nie mogą być aliasami, pomyślałem, że kompilator powinien być w stanie wyemitować bardziej zoptymalizowaną wersję kodu.

Kiedy testuję poniższy kod i kompiluję go za rustc 1.35.0pomocą -C opt-level=3 --emit obj,

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

generuje:

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

Nie korzysta to z gwarancji ai bnie może być alias.

Czy to dlatego, że obecny kompilator Rust jest wciąż w fazie rozwoju i nie wprowadził jeszcze analizy aliasów w celu optymalizacji?

Czy to dlatego, że jest jeszcze szansa, że ai bmoże alias, nawet w bezpiecznym Rust?

Rdza pierwotnie nie pozwalają LLVM za noaliasatrybut, ale ten kod spowodowanych miscompiled . Gdy wszystkie obsługiwane wersje LLVM nie będą już błędnie kompilować kodu, zostanie on ponownie włączony .

Jeśli dodasz -Zmutable-noalias=yesdo opcji kompilatora, otrzymasz oczekiwany zestaw:

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

Mówiąc najprościej, Rust umieścił wszędzie odpowiednikrestrict słowa kluczowego C , o wiele bardziej rozpowszechniony niż jakikolwiek zwykły program C. To ćwiczyło narożne przypadki LLVM więcej niż było w stanie poprawnie obsłużyć. Okazuje się, że programiści C i C ++ po prostu nie używają tak często, jak w Rust.restrict&mut

Stało się to wiele razy .

• Rdza od 1.0 do 1.7 - noaliaswłączona
• Rdza od 1.8 do 1.27 - noaliaswyłączone
• Rdza od 1.28 do 1.29 - noaliaswłączony
• Rdza od 1.30 do ??? - noaliaswyłączone

Powiązane problemy z rdzą

• Obecna sprawa

  • Niepoprawne generowanie kodu dla Matrix nalgebra :: swap_rows () # 54462
  • Ponownie włącz adnotacje noalias domyślnie, gdy LLVM już ich nie zepsuje # 54878

• Poprzednia sprawa

  • Obejdź błąd optymalizatora LLVM, nie oznaczając i nie mutując wskaźników jako noalias # 31545
  • Oznacz i mutuj wskaźniki jako noalias, gdy LLVM nie będzie ich już źle kompilować # 31681

• Inny

  • skorzystaj z metadanych nr 16515 Lali LMVM
  • Pominięta optymalizacja: referencje ze wskaźników nie są traktowane jako noalias # 38941
  • noalias to za mało # 53105
  • mutable noalias: ponownie włączyć na stałe, tylko dla paniki = przerwać lub ustabilizować flagę? # 45029