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

[lewis1revill]

Sorry for commenting on a closed issue, but this test is regressing for us with a custom target, because the problematic transformation foldBoolSelectToLogic still runs on the IR for fn test. This is after updating to LLVM 19.

To me, it's clear to see why the transformation is invalid, but for seemingly different reasons than the above fix addresses. The IR is:

; main::test
; Function Attrs: noinline nounwind
define internal fastcc void @_ZN4main4test17h24436c5bdc3836e4E(i8 %mode.0.val, i8 %mode.1.val) unnamed_addr #2 {
start:
  %trunc = trunc nuw i8 %mode.0.val to i1
  %0 = trunc nuw i8 %mode.1.val to i1
  %1 = select i1 %trunc, i1 true, i1 %0
  %.sink = select i1 %1, i8 2, i8 0
; call main::check
  tail call fastcc void @_ZN4main5check17h13ab3f87dc46addbE(i8 noundef %.sink) #5
  ret void
}

Which represents a logical, short-circuiting or operation on %mode.0.val and %mode.1.val. And since %mode.1.val is not marked as noundef, it shouldn't be valid to transform that operation into a bitwise or, since %mode.1.val being undefined now has an effect on the result regardless of whether %mode.0.val is true or not.

Does anyone have a theory as to why this fix used to work, but seems to no longer work? Frustratingly, the testcase still passes for x86_64, but that doesn't mean anything about this fix because they have switched to using GlobalISel.

[jieyouxu]

Can you instead open a new issue? This is a really old closed issue so likely has very limited visibility.