Pourquoi le compilateur Rust n'optimise-t-il pas le code en supposant que deux références mutables ne peuvent pas être alias?

Pour autant que je sache, l'alias de référence / pointeur peut entraver la capacité du compilateur à générer du code optimisé, car ils doivent garantir que le binaire généré se comporte correctement dans le cas où les deux références / pointeurs sont effectivement des alias. Par exemple, dans le code C suivant,

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

une fois compilé clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)avec le -O3drapeau, il émet

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

Ici, le code stocke (%rdi)deux fois au cas où int *aet int *balias.

Lorsque nous disons explicitement au compilateur que ces deux pointeurs ne peuvent pas être alias avec le restrictmot clé:

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

Ensuite, Clang émettra une version plus optimisée du code binaire:

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

Étant donné que Rust s'assure (sauf dans le code non sûr) que deux références mutables ne peuvent pas être alias, je pense que le compilateur devrait être capable d'émettre la version la plus optimisée du code.

Lorsque je teste avec le code ci-dessous et que je le compile rustc 1.35.0avec -C opt-level=3 --emit obj,

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

il génère:

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

Cela ne profite pas de la garantie que aet bne peut pas alias.

Est-ce parce que le compilateur Rust actuel est toujours en développement et n'a pas encore intégré d'analyse d'alias pour faire l'optimisation?

Est-ce parce qu'il y a encore une chance aet bpourrait alias, même en toute sécurité Rust?

Rust à l' origine fait permettre de LLVM noaliasattribut, mais cela fait un code mal compilée . Lorsque toutes les versions de LLVM prises en charge ne compileront plus le code, il sera réactivé .

Si vous ajoutez -Zmutable-noalias=yesaux options du compilateur, vous obtenez l'assembly attendu:

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

Autrement dit, Rust a mis l'équivalent du restrictmot - clé C partout , bien plus répandu que n'importe quel programme C habituel. Cela a exercé les cas d'angle de LLVM plus qu'il n'était capable de gérer correctement. Il s'avère que les programmeurs C et C ++ n'utilisent tout simplement pas restrictaussi fréquemment que &mutdans Rust.

Cela s'est produit plusieurs fois .

• Rust 1.0 à 1.7 - noaliasactivé
• Rust 1.8 à 1.27 - noaliasdésactivé
• Rust 1.28 à 1.29 - noaliasactivé
• Rouille 1,30 à ??? - noaliasdésactivé

Problèmes de rouille associés

• Cas actuel

  • Génération de code incorrecte pour la matrice de nalgebra :: swap_rows () # 54462
  • Réactivez les annotations de noalias par défaut une fois que LLVM ne les a plus mal compilées # 54878

• Cas précédent

  • Solution de contournement du bogue de l'optimiseur LLVM en ne marquant pas & pointeurs mut comme noalias # 31545
  • Marquer et muter les pointeurs comme noalias une fois que le LLVM ne les a plus mal compilés # 31681

• Autre

  • utiliser les métadonnées noalias de portée LLVM # 16515
  • Optimisation manquée: les références des pointeurs ne sont pas traitées comme des noalias # 38941
  • noalias ne suffit pas # 53105
  • noalias mutables: réactiver définitivement, uniquement pour panique = abandonner, ou stabiliser le drapeau? # 45029