Redundant bounds check when indexing array with enum in Rust 1.90

[ictrobot]

Code

I tried this code:

fn test(instructions: &[Instruction], registers: [u32; 4]) -> u32 {
    if let Some(&instruction) = instructions.get(0) {
        match instruction {
            Instruction::A(a) => registers[a as usize],
            Instruction::B(b) => registers[b as usize],
        }
    } else {
        0
    }
}

#[derive(Copy, Clone)]
enum Instruction {
    A(Register),
    B(Register),
}

#[derive(Copy, Clone)]
enum Register {
    A,
    B,
    C,
    D,
}

I expected to see this happen: No bounds check is emitted

Instead, this happened: There's a bounds check accessing registers

Version it worked on

It most recently worked on: Rust 1.89

Version with regression

rustc --version --verbose:

rustc 1.90.0 (1159e78c4 2025-09-14)
binary: rustc
commit-hash: 1159e78c4747b02ef996e55082b704c09b970588
commit-date: 2025-09-14
host: x86_64-unknown-linux-gnu
release: 1.90.0
LLVM version: 20.1.8

Also checked in nightly:

rustc 1.92.0-nightly (53a741fc4 2025-10-16)
binary: rustc
commit-hash: 53a741fc4b8cf2d8e7b1b2336ed8edf889db84f4
commit-date: 2025-10-16
host: x86_64-unknown-linux-gnu
release: 1.92.0-nightly
LLVM version: 21.1.3

Bisected to b56aaec / #144389 using cargo-bisect-rustc

[ictrobot]

<     if let Some(&instruction) = instructions.get(0) {
<         match instruction {
---
>     if let Some(instruction) = instructions.get(0) {
>         match *instruction {

Moving the deference to the match is enough to avoid the bounds check

[hanna-kruppe]

The initial LLVM IR has the necessary !range metadata to eliminate the bounds checks, e.g.:

bb2:                                              ; preds = %bb8
  %12 = getelementptr inbounds i8, ptr %instruction, i64 1
  %b = load i8, ptr %12, align 1, !range !6, !noundef !3
  %_12 = zext i8 %b to i64
  %_13 = icmp ult i64 %_12, 4
  br i1 %_13, label %bb5, label %panic1

However, SROA drops this information when it replaces those loads with the value initially loaded from instructions[0] and stashed in the %instruction alloca due to the by-value pattern matching. That initial load doesn't have the !range metadata. The loads that do have the metadata are conditional (more conditional than the initial load, anyway), so it would in general be incorrect to hoist the metadata on the earlier load that's being reused. In this particular case it I believe it could be justified by noticing that all paths from that load onward eventually do a load with the same !range metadata, but that seems very fragile and complicated, and wouldn't help for many other cases.

In this specific case, rustc could potentially be smarter by noticing the second element of the ScalarPair has the same valid range across all variants. But that wouldn't help with minor variations like enum Instruction { Push(Register), Pop(Register), Const(u8), Add }.

So yeah, the bisection pointing at #144389 seems correct. cc @scottmcm