Почему компилятор 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 *aи int *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помощью -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 все еще находится в разработке и еще не включил анализ псевдонимов для оптимизации?

Это потому , что есть еще шанс , что aи bможет псевдоним, даже в безопасном Rust?

Ржавчина первоначально сделал включить LLVM в noaliasатрибут, но этот причиненный miscompiled код . Когда все поддерживаемые версии LLVM больше не будут неправильно компилировать код, он будет снова включен .

Если вы добавите -Zmutable-noalias=yesв параметры компилятора, вы получите ожидаемую сборку:

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

Проще говоря, Rust повсеместно использует эквивалент restrictключевого слова C , гораздо более распространенный, чем любая обычная программа на C. Это использовало угловые случаи LLVM больше, чем он мог правильно обработать. Оказывается, программисты на C и C ++ просто не используют так часто, как в Rust.restrict&mut

Это происходило несколько раз .

• Руст с 1.0 по 1.7 - noaliasвключен
• Руст от 1,8 до 1,27 - noaliasотключено
• Руст от 1.28 до 1.29 - noaliasвключен
• Руст 1.30 через ??? - noaliasотключен

Связанные проблемы ржавчины

• Текущий случай

  • Неправильная генерация кода для матрицы nalgebra :: swap_rows () # 54462
  • Повторно включить аннотации noalias по умолчанию, как только LLVM больше не будет их неправильно компилировать # 54878

• Предыдущий случай

  • Обходной путь оптимизатора LLVM, не помечая указатели & mut как noalias # 31545
  • Помечать указатели & mut как noalias, если LLVM больше их не компилирует # 31681

• Другой

  • использовать метаданные noalias в области LLVM # 16515
  • Пропущенная оптимизация: ссылки из указателей не рассматриваются как noalias # 38941
  • не хватает noalias # 53105
  • изменяемые noalias: повторно включить постоянно, только для panic = abort или флаг стабилизации? # 45029