ptr::read() is slower than directly dereferencing

[jrmuizel]

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

pub fn foo(v: *const Foo) -> Foo {
    let k: Option<Foo> = unsafe { Some(*v) };
    return k.unwrap();
}

compiles to

example::foo:
        mov     al, byte ptr [rdi]
        ret

but replacing *v with v.read()

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

pub fn foo(v: *const Foo) -> Foo {
    let k: Option<Foo> = unsafe { Some(v.read()) };
    return k.unwrap();
}

compiles to:

example::foo:
        push    rax
        mov     al, byte ptr [rdi]
        cmp     al, 4
        je      .LBB0_1
        pop     rcx
        ret
.LBB0_1:
        lea     rdi, [rip + .L__unnamed_1]
        lea     rdx, [rip + .L__unnamed_2]
        mov     esi, 43
        call    qword ptr [rip + core::panicking::panic@GOTPCREL]
        ud2

This came up from #71257

[alex]

godbolt for the bad version here: https://rust.godbolt.org/z/CWboVo

took me a second, but the panic is from the unwrap, suggesting that the discriminant range isn't propagated correctly

[jrmuizel]

This is presumably because the copy_nonoverlapping in the implementation of ptr::read() does not emit range metadata.

[hanna-kruppe]

This matches my impression from skimming over -print-after-all output, though I'll add that the call to ptr::read() does have the range metadata, so if that metadata got propagated before or during inlining, we'd probably be in a better position. But a simpler solution in the short term might be to implement ptr::read with a compiler intrinsic instead of the current MaybeUninit+copy_nonoverlapping contraption.

[scottmcm]

LLVM-IR diff: https://rust.godbolt.org/z/vMex9ooxq

Looks like the root cause is that read doesn't get !range metadata:

-  %_3 = load i8, ptr %v, align 1, !dbg !11, !range !13, !noundef !10
+  %tmp.0.copyload = load i8, ptr %v, align 1, !dbg !11

Will hopefully be fixed by #109035

[scottmcm]

Test: https://github.com/rust-lang/rust/blob/master/tests/codegen/issues/issue-73258.rs