MIR optimization produces worse code by losing provenance information

[nbdd0121]

I tried this code:

unsafe extern "C" {
    safe fn foo();
}

pub fn example() {
    let x = 1;
    println!("{x}");
    if x != 1 {
        foo();
    }
}

With -O, the foo() call cannot be optimized away. It can be optimized away however, if I use -Zmir-opt-level=0.

https://godbolt.org/z/c5qE7Tvsf

My hypothesis is that:

• format_args takes x by reference
• This x is annotated as noalias when passing to relevant Argument constructors
• If inlining is done by LLVM, it makes use of this information and correctly deduce that x cannot change during std::io::stdio::_print
• If inlining is done by Rust at MIR level, this information is lost, and all LLVM sees is that a pointer is put into Argument and this Argument is passed to std::io::stdio::_print, and hence it has to assume conservatively that the value may change.

This was affecting Rust-for-Linux as we have a build_assert! which performs build-time assertions by requiring calls to be optimized away (Rust equivalent of C's BUILD_BUG_ON), and @joelagnel discovered that adding a print can cause such assertion to trip up.

@rustbot label: +A-rust-for-linux +I-slow +I-heavy

[nikic]

I think this case is not related to aliasing information, but to the new captures(address, read_provenance) attribute supported since LLVM 21 (which is why this does not optimize on stable even with -Z mir-opt-level=0).

Supporting something like store ptr %x, ptr %args, !captures !{!"address", !"read_provenance"} is a possible future extension I'm considering, which should be able to handle this after inlining as well...

[nikic]

I've implemented the metadata on the LLVM side in llvm/llvm-project#160913, and confirmed that the test case here is successfully optimized with this Rust patch: nikic@45f02bc

Though based on @RalfJung's comment at rust-lang/unsafe-code-guidelines#371 (comment), it seems like the correctness of this approach is not quite as obvious as I initially assumed...

[RalfJung]

Though based on @RalfJung's comment at rust-lang/unsafe-code-guidelines#371 (comment), it seems like the correctness of this approach is not quite as obvious as I initially assumed...

It's more that you have added another item to the list of constraints that the aliasing system needs to satisfy. I don't necessarily mind that, extra constraints can simplify design choices by restricting the design space. I just didn't know before that this is a constraint you'd like to impose.

Definitely please ping t-opsem before making use of this in rustc. :)