Inefficient codegen for `eq` of enum with identical variants

[adrian17]

Given an enum:

type Pointer = *const ();
#[derive(PartialEq, Eq)]
pub enum MyEnum {
    A(Pointer),
    B(Pointer),
    C(Pointer),
    D(Pointer),
    E(Pointer),
    F(Pointer),
    Any,
}

The generated comparison uses jump table despite every jump target being identical:
https://godbolt.org/z/6nWW53eb5
As far as I'm aware, this jump should have been optimized away entirely, probably to something like

example::compare:
        mov     rax, qword ptr [rdi]
        cmp     rax, qword ptr [rsi]
        jne     .LBB0_1
        cmp     rax, 5
        ja      .LBB0_3
-        lea     rcx, [rip + .LJTI0_0]
-        movsxd  rax, dword ptr [rcx + 4*rax]
-        add     rax, rcx
-        jmp     rax
-.LBB0_5:
        mov     rax, qword ptr [rdi + 8]
        cmp     rax, qword ptr [rsi + 8]
        sete    al
        ret

With WASM target, it's even worse, as it doesn't deduplicate the identical match arms at all:
https://godbolt.org/z/Gf16rM4MY

[saethlin]

Looks similar to #55030

I minimized this a bit to

#[derive(PartialEq, Eq)]
pub enum MyEnum {
    A(u64),
    B(u64),
    C(u64),
}

pub fn compare(a: &MyEnum, b: &MyEnum) -> bool {
    *a == *b
}

Which emits different LLVM IR with -O and -Copt-level=3. Both have a switch which leads to the same blocks. For 3 variants, if I make the payload u32 something cleans up the jump table when lowering to x86_64. Adding another variant inhibits that.

Here is the IR for the code above with -Copt-level=3:

define noundef zeroext i1 @_ZN7example7compare17had18f8c96abc6decE(ptr noalias nocapture noundef readonly align 4 dereferenceable(8) %a, ptr noalias nocapture noundef readonly align 4 dereferenceable(8) %b) unnamed_addr #0 !dbg !6 {
start:
  %a.val = load i32, ptr %a, align 4, !dbg !11, !range !12, !noundef !10
  %0 = getelementptr i8, ptr %a, i64 4, !dbg !11
  %a.val1 = load i32, ptr %0, align 4, !dbg !11
  %b.val = load i32, ptr %b, align 4, !dbg !11, !range !12, !noundef !10
  %1 = getelementptr i8, ptr %b, i64 4, !dbg !11
  %b.val2 = load i32, ptr %1, align 4, !dbg !11
  %_5.i = icmp eq i32 %a.val, %b.val, !dbg !13
  br i1 %_5.i, label %bb2.i, label %"_ZN56_$LT$example..MyEnum$u20$as$u20$core..cmp..PartialEq$GT$2eq17h895d84d9838af47eE.exit", !dbg !13

bb2.i:                                            ; preds = %start
  switch i32 %a.val, label %bb5.i [
    i32 0, label %bb4.i
    i32 1, label %bb6.i
    i32 2, label %bb7.i
  ], !dbg !13

bb5.i:                                            ; preds = %bb2.i
  unreachable, !dbg !19

bb4.i:                                            ; preds = %bb2.i
  %2 = icmp eq i32 %a.val1, %b.val2, !dbg !21
  br label %"_ZN56_$LT$example..MyEnum$u20$as$u20$core..cmp..PartialEq$GT$2eq17h895d84d9838af47eE.exit", !dbg !23

bb6.i:                                            ; preds = %bb2.i
  %3 = icmp eq i32 %a.val1, %b.val2, !dbg !24
  br label %"_ZN56_$LT$example..MyEnum$u20$as$u20$core..cmp..PartialEq$GT$2eq17h895d84d9838af47eE.exit", !dbg !23

bb7.i:                                            ; preds = %bb2.i
  %4 = icmp eq i32 %a.val1, %b.val2, !dbg !26
  br label %"_ZN56_$LT$example..MyEnum$u20$as$u20$core..cmp..PartialEq$GT$2eq17h895d84d9838af47eE.exit", !dbg !23

"_ZN56_$LT$example..MyEnum$u20$as$u20$core..cmp..PartialEq$GT$2eq17h895d84d9838af47eE.exit": ; preds = %start, %bb4.i, %bb6.i, %bb7.i
  %.0.i = phi i1 [ false, %start ], [ %4, %bb7.i ], [ %3, %bb6.i ], [ %2, %bb4.i ]
  ret i1 %.0.i, !dbg !28
}

---

It is technically possible to optimize out these duplicate match arms before LLVM, but probably waste of time given the current state of MIR. I think special-casing the derive macro might be better, if we don't want to wait for LLVM.

[dianqk]

Upstream issue: llvm/llvm-project#64031.

[dianqk]

@rustbot claim

[dianqk]

@rustbot label llvm-fixed-upstream

[rustbot]

Error: Label llvm-fixed-upstream can only be set by Rust team members

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #t-infra on Zulip.