[MIR-opt] trivial matches aren't optimized out at mir-opt-level=1

[scottmcm]

I got excited by and went to try out SimplifyArmIdentity+SimplifyBranchSame from #66282, but was surprised that the first thing I attempted didn't actually get optimized away as I'd expected.

pub fn demo(x: Result<u32, i32>) -> Result<u32, i32> {
    match x {
        Ok(v) => Ok(v),
        Err(e) => Err(e),
    }
}

Repro: https://rust.godbolt.org/z/bxFAsP

It does, however, optimize away in MIR with -Z mir-opt-level=2.

(Note that this is the simple case without ?, where there are no function calls involved so inlining should be irrelevant.)

Seems like there's a gap here? cc @Centril @oli-obk @wesleywiser

Some guesses from the discord conversation where centril asked me to open this issue: the Storage{Live|Dead} presence, extra copies because [ui]32, const prop hiding something, ...

[oli-obk]

You can run with -Zdump-mir locally with each -Zmir-opt-level and diff the resulting directories full of mir dumps. Then you'll see where stuff starts to diverge, which should pinpoint where we need to change something

[matthewjasper]

I'm surprised that this was merged without explicitly requiring -Zmir-opt-level=2.

[oli-obk]

@matthewjasper well... we don't have any policy about this afaik. Should we establish one? I like level 1 because it gives us good testing (as the issues have shown), but I also see that exposing new optimizations directly will likely cause problems again in the future

[Centril]

Rather than using mir-opt-level=2, we could limit new optimizations to nightly compilers instead?

[bjorn3]

Or maybe use -Zmir-opt-level=2 as default for nightly.

[matthewjasper]

Given that bugs were found in this pass even with it requiring a Z-flag, I'm not really concerned about testing, at least for a few weeks. Having nightly not mirror stable in something with such a poor track record as newly added mir optimisations sounds terrible.