Компилятор Rust автоматически удаляет ненужные промежуточные переменные? - PullRequest
1 голос
/ 09 июля 2020

В некоторых языках мне говорят, что компилятор будет выполнять оптимизацию, которая удаляет ненужные «промежуточные» локальные переменные для повышения эффективности выполнения.

Кто-нибудь знает, делает ли Rust то же самое? Например, рассмотрим следующие фрагменты кода:

fn main() {
    // has four local variables
    let x = 3;
    let y = 5;
    let temp_result = x + y;
    let final_result = temp_result * 40;
    println!("The final result is: {}", final_result);
}

Сравните с приведенной ниже реализацией, которая, по-видимому, имеет ноль явно созданных локальных переменных

fn main() {
    // has no explicitly created local variables
    println!("The final result is: {}", (3+5) * 40);
}

Будет ли генерироваться идентичная машина code?

Иначе говоря, «понимает» ли компилятор, что четыре локальные переменные в первой реализации доказуемо эквивалентны, учитывая жестко заданные целочисленные входы, второй реализации?

1 Ответ

4 голосов
/ 09 июля 2020

Вот ссылка на игровую площадку на тестовую версию. Рассмотрим сборку, созданную в режиме выпуска:

playground::main:
    pushq   %r15
    pushq   %r14
    pushq   %r12
    pushq   %rbx
    subq    $72, %rsp
    ####################### f1() here
    movl    $320, 4(%rsp) # whole function optimized to static value of 320
    #######################
    leaq    4(%rsp), %r14
    movq    %r14, 8(%rsp)
    movq    core::fmt::num::imp::<impl core::fmt::Display for i32>::fmt@GOTPCREL(%rip), %r15
    movq    %r15, 16(%rsp)
    leaq    .L__unnamed_2(%rip), %rax
    movq    %rax, 24(%rsp)
    movq    $2, 32(%rsp)
    movq    $0, 40(%rsp)
    leaq    8(%rsp), %rbx
    movq    %rbx, 56(%rsp)
    movq    $1, 64(%rsp)
    movq    std::io::stdio::_print@GOTPCREL(%rip), %r12
    leaq    24(%rsp), %rdi
    callq   *%r12
    ####################### f2() here
    movl    $320, 4(%rsp) # same as with f1()
    #######################
    movq    %r14, 8(%rsp)
    movq    %r15, 16(%rsp)
    leaq    .L__unnamed_3(%rip), %rax
    movq    %rax, 24(%rsp)
    movq    $2, 32(%rsp)
    movq    $0, 40(%rsp)
    movq    %rbx, 56(%rsp)
    movq    $1, 64(%rsp)
    leaq    24(%rsp), %rdi
    callq   *%r12
    addq    $72, %rsp
    popq    %rbx
    popq    %r12
    popq    %r14
    popq    %r15
    retq

Поскольку возвращаемые значения в вашем примере известны статически, функции даже не отображаются в скомпилированном коде. Фактически вы получите то же самое, даже если определите функции следующим образом:

fn f1(a: i32, b: i32, c:i32) -> i32 {
    let x = a;
    let y = b;
    let temp_result = x + y;
    let final_result = temp_result * c;
    final_result
}

fn f2(a: i32, b: i32, c: i32) -> i32 {
    (a + b) * c
}

pub fn main() {
    println!("f1() = {}", f1(3, 5, 40));
    println!("f2() = {}", f2(3, 5, 40));
}

Что произойдет, если параметры неизвестны во время компиляции? Вот еще одна игровая площадка , на этот раз со значениями, вычисляемыми случайным образом и с тегами для обеих функций #[inline(never)]:

playground::f1:
    leal    (%rdi,%rsi), %eax
    imull   %edx, %eax
    retq

playground::main:
    # rng initialization...

.LBB7_20:
    movl    8(%rbp,%rax,4), %ebx
    addq    $1, %rax
    movq    %rax, (%rbp)
    movl    %r15d, %edi
    movl    %r12d, %esi
    movl    %ebx, %edx
    ######################## f1() called here
    callq   playground::f1 #
    ########################
    movl    %eax, 4(%rsp)
    leaq    4(%rsp), %rax
    movq    %rax, 8(%rsp)
    movq    core::fmt::num::imp::<impl core::fmt::Display for i32>::fmt@GOTPCREL(%rip), %r13
    movq    %r13, 16(%rsp)
    leaq    .L__unnamed_3(%rip), %rax
    movq    %rax, 24(%rsp)
    movq    $2, 32(%rsp)
    movq    $0, 40(%rsp)
    leaq    8(%rsp), %rbp
    movq    %rbp, 56(%rsp)
    movq    $1, 64(%rsp)
    movq    std::io::stdio::_print@GOTPCREL(%rip), %r14
    leaq    24(%rsp), %rdi
    callq   *%r14
    movl    %r15d, %edi
    movl    %r12d, %esi
    movl    %ebx, %edx
    ######################## and again here!
    callq   playground::f1 #
    ########################
    # ...
    retq

Компилятор действительно распознал, что функции идентичны, и свернул их в единственное определение.

...