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.

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