¿Por qué el compilador Rust no optimiza el código suponiendo que dos referencias mutables no pueden tener alias?

Hasta donde yo sé, el alias de referencia / puntero puede dificultar la capacidad del compilador para generar código optimizado, ya que deben garantizar que el binario generado se comporte correctamente en el caso en que las dos referencias / punteros realmente alias. Por ejemplo, en el siguiente código C,

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

cuando se compila clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)con la -O3bandera, 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

Aquí el código se almacena (%rdi)dos veces en mayúsculas int *ay minúsculas int *b.

Cuando explícitamente le decimos al compilador que estos dos punteros no pueden alias con la restrictpalabra clave:

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

Entonces Clang emitirá una versión más optimizada del código binario:

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

Dado que Rust se asegura (excepto en un código inseguro) de que dos referencias mutables no pueden tener alias, creo que el compilador debería poder emitir la versión más optimizada del código.

Cuando pruebo con el siguiente código y lo compilo rustc 1.35.0con -C opt-level=3 --emit obj,

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

genera:

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

Esto no aprovecha la garantía ay bno puede alias.

¿Es esto porque el compilador Rust actual todavía está en desarrollo y aún no ha incorporado el análisis de alias para hacer la optimización?

¿Es esto porque todavía hay una posibilidad de que ay bpodría alias, incluso en Rust seguro?

Rust originalmente hizo permitirá LLVM de noaliasatributo, pero este código miscompiled causado . Cuando todas las versiones de LLVM compatibles ya no compilan mal el código, se volverá a habilitar .

Si agrega -Zmutable-noalias=yesa las opciones del compilador, obtiene el ensamblado esperado:

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

En pocas palabras, Rust puso el equivalente de la restrictpalabra clave de C en todas partes , mucho más frecuente que cualquier programa habitual de C. Esto ejerció casos de esquina de LLVM más de lo que pudo manejar correctamente. Resulta que los programadores C y C ++ simplemente no usan con restricttanta frecuencia como &mutse usa en Rust.

Esto ha sucedido varias veces .

• Rust 1.0 a 1.7 - noaliashabilitado
• Rust 1.8 a 1.27 - noaliasdeshabilitado
• Rust 1.28 a 1.29 - noaliashabilitado
• Rust 1.30 a través de ??? - noaliasdeshabilitado

Problemas relacionados con el óxido

• Caso actual

  • Generación de código incorrecta para la matriz de nalgebra :: swap_rows () # 54462
  • Vuelva a habilitar las anotaciones de noalias por defecto una vez que LLVM ya no las compile mal # 54878

• Caso anterior

  • Solución alternativa del optimizador de LLVM al no marcar y mut punteros como noalias # 31545
  • Marca y mut apuntadores como noalias una vez que LLVM ya no los compila mal # 31681

• Otro

  • hacer uso de los metadatos de noalias con alcance de LLVM # 16515
  • Optimización perdida: las referencias de punteros no se tratan como noalias # 38941
  • Noalias no es suficiente # 53105
  • noalias mutables: ¿volver a habilitar permanentemente, solo para pánico = abortar, o estabilizar la bandera? # 45029