Codegen depends on let-variable ordering for unclear reasons

[CrazyboyQCD]

https://godbolt.org/z/Wx1rvE6vq

use std::borrow::Cow;

pub struct Error {
    message: Cow<'static, str>,
    cause: Option<Box<[u8]>>,
}
#[no_mangle]
pub fn declear_before(v: u64) -> Error {
    let s = format!("{v}");
    let mut e = Error {
        message: Cow::Borrowed(""),
        cause: None,
    };
    e.message = s.into();
    e
}

Declear s before Error produces better codegen than declear after.

[workingjubilee]

@CrazyboyQCD even better codegen, btw:

use std::borrow::Cow;

pub struct Error {
    message: Cow<'static, str>,
    cause: Option<Box<u8>>,
}

#[no_mangle]
pub fn declear_after(v: u64) -> Error {
    Error {
        message: Cow::from(format!("{v}")),
        cause: None,
    }
}

[CrazyboyQCD]

I know, but in my use case it is a builder pattern.

[saethlin]

If you add -Cpanic=abort, both examples produce the same codegen. The problem is the order of function calls, not let statements, and the limitations of LLVM's interprocedural optimizations.

In the slow example, we construct an Error which has a complicated Drop impl, then we call a function that may unwind (alloc::fmt::format::format_inner) and if that does unwind, we need to jump to a call to drop_in_place<Error> before unwinding out of the example function.

In the fast example, when we call format_inner there is nothing in the stack frame that needs to be dropped, so the unwind edge doesn't interfere with any optimizations.

What could save the slow example is if the drop_in_place for Error were inlined, because then LLVM could probably const-propagate the value of cause across the function call and delete all the cleanup code (the String needs to be deallocated either way). I can't figure out why drop_in_place isn't inlined.

Great example of why I detest unwinding panics!