Miscompilation when matching on an enum after printing Hello world

[kocsis1david]

I tried this code:

enum Pass {
    Opaque {
        clear_color: [f32; 4],
        with_depth_pre_pass: bool,
    },
    Transparent,
}

enum LoadOp {
    Clear,
    Load,
}

#[inline(never)]
fn check(x: Option<LoadOp>) {
    assert!(x.is_none());
}

#[inline(never)]
fn test(mode: Pass) {
    check(match mode {
        Pass::Opaque {
            with_depth_pre_pass: true,
            ..
        }
        | Pass::Transparent => None,
        _ => Some(LoadOp::Clear),
    });
}

fn main() {
    println!("Hello, world!");
    test(Pass::Transparent);
}

The assertion shouldn't fail, because pass is Pass::Transparent and so the parameter to the function check should be None, but the assertion still fails.

Meta

rustc --version --verbose:

rustc 1.73.0-nightly (08d00b40a 2023-08-09)
binary: rustc
commit-hash: 08d00b40aef2017fe6dba3ff7d6476efa0c10888
commit-date: 2023-08-09
host: x86_64-unknown-linux-gnu
release: 1.73.0-nightly
LLVM version: 17.0.0

It seems that the bug only occurs when using opt-level=1 or opt-level=2 and after updating to LLVM 17.

[nikic]

define i8 @test(ptr %p) {
  %v1 = load i8, ptr %p, align 4, !range !0, !noundef !{}
  %cmp1 = icmp eq i8 %v1, 0
  %p2 = getelementptr inbounds i8, ptr %p, i64 1
  %v2 = load i8, ptr %p2, align 1, !range !0
  %cmp2 = icmp eq i8 %v2, 0
  %or = select i1 %cmp1, i1 %cmp2, i1 false
  %res = select i1 %or, i8 0, i8 2
  ret i8 %res
}

!0 = !{i8 0, i8 2}

Results in:

	movzbl	(%rdi), %eax
	orb	1(%rdi), %al
	addb	%al, %al
	retq

This makes use of the !range on the second load in a way that is not legal (note the absence of !noundef -- and the memory is indeed uninitialized).

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-critical +T-compiler

[nikic]

Upstream issue: llvm/llvm-project#64589