Optimize out nop-matches

[oli-obk]

The ? operator is not zero cost right now, because the matches generated by it don't get optimized as well as they could.

Looking at https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=627df52e7c476667ecf9a9831eecf829

I see

_3 = ((_1 as Ok).0: u32);
_4 = _3;
((_0 as Ok).0: u32) = move _4;
discriminant(_0) = 0;

and

_5 = ((_1 as Err).0: i32);
_6 = _5;
((_0 as Err).0: i32) = move _6;
discriminant(_0) = 1;

Which we could reasonably write a peephole optimization for getting transformed to

_0 = _1

each

Then a second optimization could find switchInt terminators where all basic blocks are the same and eliminate the switchInt by replacing it to a goto to the first basic block being switched to.

This will even benefit matches where only one arm is a nop, because that arm will just become a memcopy

[oli-obk]

Ideally we'd not even limit ourselves to going from an enum to the same enum, but moving from one enum to another as long as the layouts match up. Though that may require the insertion of a transmute call. We can start with just figuring out that an enum variant gets all its fields read and then the variant is recreated to produce the exact same variant.

[Aaron1011]

Ideally we'd not even limit ourselves to going from an enum to the same enum, but moving from one enum to another as long as the layouts match up.

This could apply to structs as well. For example, in:

struct Foo {
    a: usize,
    b: bool
}

fn bar(val: Foo) -> Foo {
    let new = Foo {
        a: val.a,
        b: val.b
    };
    new
}

bar could be optimized to a single assignment.

[ghost]

Does this issue have something to do with the performance problem described in #37939?

[oli-obk]

Does this issue have something to do with the performance problem described in #37939?

yes. That's what inspired this optimization idea

[Mark-Simulacrum]

We've landed the first iteration here (#66282) and the followup for enabling this more widely is likely closing out #66855 so I'm closing this issue in favor of that.

[Centril]

There's still some work here to be done:

• We check for an exact match in the enum types, but different types with the same layouts are also fine from an operational POV.

• ? being optimized requires -Zmir-opt-level=2 so that the inlining pass triggers. We might want to consider #[rustc_mir_inline] or some such on targeted functions so that we do optimize ? without -Zmir-opt-level=2. Alternatively, we fix the inlining pass somehow.