Missed Optimization for NonZeroU32 to NonZeroUsize Conversions

[zmtaub]

I tried this code:

use std::num::*;

pub fn f0(x: u32) -> u64 {
    x.try_into().unwrap()
}

pub fn f1(x: NonZeroU32) -> NonZeroU64 {
    x.try_into().unwrap()
}

pub fn f2(x: u32) -> usize {
    x.try_into().unwrap()
}

pub fn f3(x: NonZeroU32) -> NonZeroUsize {
    x.try_into().unwrap()
}

I expected to see this happen:

I expected equivalent assembly generated for each function on 64-bit platforms when compiling with -C opt-level=3.
Indeed, if f3 is removed, this assembly is generated according to Compiler Explorer:

example::f0:
        mov     eax, edi
        ret

Instead, this happened:

According to Compiler Explorer, this assembly is generated:

core::ptr::drop_in_place<core::num::error::TryFromIntError>:
        ret

example::f0:
        mov     eax, edi
        ret

example::f3:
        test    edi, edi
        je      .LBB2_1
        mov     eax, edi
        ret
.LBB2_1:
        push    rax
        lea     rdi, [rip + .L__unnamed_1]
        lea     rcx, [rip + .L__unnamed_2]
        lea     r8, [rip + .L__unnamed_3]
        lea     rdx, [rsp + 7]
        mov     esi, 43
        call    qword ptr [rip + core::result::unwrap_failed@GOTPCREL]
        ud2

.L__unnamed_1:
        .ascii  "called `Result::unwrap()` on an `Err` value"

.L__unnamed_2:
        .quad   core::ptr::drop_in_place<core::num::error::TryFromIntError>
        .asciz  "\000\000\000\000\000\000\000\000\001\000\000\000\000\000\000"
        .quad   <core::num::error::TryFromIntError as core::fmt::Debug>::fmt

.L__unnamed_4:
        .ascii  "/app/example.rs"

.L__unnamed_3:
        .quad   .L__unnamed_4
        .asciz  "\017\000\000\000\000\000\000\000\020\000\000\000\022\000\000"

The try_into().unwrap() isn't optimized away for f3, unlike the other functions.

Compiler Explorer link

Meta

rustc --version --verbose:

rustc 1.74.0 (79e9716c9 2023-11-13)
binary: rustc
commit-hash: 79e9716c980570bfd1f666e3b16ac583f0168962
commit-date: 2023-11-13
host: x86_64-unknown-linux-gnu
release: 1.74.0
LLVM version: 17.0.4

[Jules-Bertholet]

@rustbot label C-optimization I-heavy I-slow T-compiler

[AngelicosPhosphoros]

As I understand, the root cause of this is that LLVM doesn't support !range metadata on values (including function arguments) and return values.

This !range metadata is used when loading values from pointers so if we pass argument by reference, compiler optimizes code correctly: godbolt.
However, it probably would not work in practice because LLVM optimizes functions by promoting references to values in argpromotion pass.

The only good thing is that if your values are stored in memory (e.g. in some vector), it would be optimized correctly.

[AngelicosPhosphoros]

Another example: godbolt

pub fn non_zero_cmp(a: NonZeroU32)->bool {
   a.get() == 0
}

It should generate just ret i1 0 but it generates test:

example::non_zero_cmp:
        test    edi, edi
        sete    al
        ret

@zmtaub May you rename your issue to "Compiler fails to optimize NonZero integers passed as function parameters"?

[AngelicosPhosphoros]

Made a LLVM issue.
llvm/llvm-project#76628

[AngelicosPhosphoros]

I started to work on issue.
#119452

[nikic]

Duplicate of #49572.