Inefficient implementation of `PartialEq` for nested (fieldless) enums

[zaneduffield]

I'm not sure if this is the right place for this (might be LLVM to blame), just a bit of inefficient code that I noticed.

https://godbolt.org/z/K57orYj5h

The only difference between the two functions eq and matches is the use of == and matches! for the enum comparison. The generated code for eq includes two calls to PartialEq for Outer, whereas the code for matches has a much simpler (inline) comparison.

Also, the generated code for PartialEq seems very inefficient, given the enum is just a two-byte value that can be directly compared.

If you tinker with the enum definitions it's not hard to cause eq to optimise exactly like matches.

Example copied here

#[derive(PartialEq)]
pub enum InnerInner {
    One,
    Two,
}

#[derive(PartialEq)]
pub enum Inner {
    One,
    Two,
    Const(InnerInner),
}

#[derive(PartialEq)]
pub enum Outer {
    One(Inner),
    Two,
    Three,
    Four,
    Five(Inner),
    Six(Inner),
    Seven(Inner),
    Eight(Inner),
}

#[no_mangle]
pub fn eq(t: Outer, b: &mut bool) {
    let token_type = if t == Outer::One(Inner::One) {
        Outer::One(Inner::One)
    } else {
        Outer::Two
    };

    *b = token_type == Outer::Two;
}

#[no_mangle]
pub fn matches(t: Outer, b: &mut bool) {
    let token_type = if matches!(t, Outer::One(Inner::One)) {
        Outer::One(Inner::One)
    } else {
        Outer::Two
    };

    *b = matches!(token_type, Outer::Two);
}

[zaneduffield]

This missed optimisation appears to have been introduced in Rust 1.65.

[workingjubilee]

Rust 1.65 was an LLVM upgrade.

[workingjubilee]

I was going to say "gonna need a benchmark" but then I actually looked at the size of that regression. Damn.

[dianqk]

One difference is that in MIR, Rust 1.65 inlined <InnerInner as PartialEq>::eq.