Repository navigation
ptr::read() is slower than directly dereferencing #73258
Description
#[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]
retbut 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]
ud2This came up from #71257
Reacted by Kornel, Jakub Beránek and Stepan Koltsov
Activity
alex commentedon Jun 11, 2020
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 commentedon Jun 13, 2020
This is presumably because the
copy_nonoverlappingin the implementation ofptr::read()does not emit range metadata.hanna-kruppe commentedon Jun 14, 2020
This matches my impression from skimming over
-print-after-alloutput, though I'll add that the call toptr::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 implementptr::readwith a compiler intrinsic instead of the current MaybeUninit+copy_nonoverlapping contraption.scottmcm commentedon Mar 12, 2023
LLVM-IR diff: https://rust.godbolt.org/z/vMex9ooxq
Looks like the root cause is that
readdoesn't get!rangemetadata:Will hopefully be fixed by #109035
scottmcm commentedon Mar 15, 2023
Test: https://github.com/rust-lang/rust/blob/master/tests/codegen/issues/issue-73258.rs