Two subsequent labels and unnecessary jmp with opt-level=s

[mickvangelderen]

The following code:

const fn checked_div_round(a: u64, b: u64) -> Option<u64> {
    match b {
        0 => None,
        1 => Some(a),
        // `a / b` is computable and `(a % b) * 2` can not overflow since `b >= 2`. UPDATE <- this is wrong
        b => Some(a / b + if (a % b) * 2 >= b { 1 } else { 0 }),
    }
}

Generates two subsequent labels and an unnecessary jmp instruction:

checked_div_round:
        test    rsi, rsi
        je      .LBB0_1
        cmp     rsi, 1
        je      .LBB0_3
        mov     rax, rdi
        xor     edx, edx
        div     rsi
        add     rdx, rdx
        cmp     rdx, rsi
        mov     rdi, rax
        sbb     rdi, -1
.LBB0_3:
        mov     esi, 1
        jmp     .LBB0_4   ; this jump does not seem necessary since `.LBB0_1` is empty
.LBB0_1:
.LBB0_4:
        mov     rax, rsi
        mov     rdx, rdi
        ret

When compiled with -C opt-level=s using rustc 1.79.0.

Godbolt: https://godbolt.org/z/fhTq3ssnK

P.S. For context, I am not too familiar with asm. I did not find any similar results while searching through the rustc and llvm issue trackers for "double | subsequent | unnecessary label" or "unnecessary jmp | jump". Please let me know how I can improve the quality of my issue reporting.

[veera-sivarajan]

@rustbot label -needs-triage +C-optimization +T-compiler +A-codegen +A-LLVM

[DianQK]

Here are multiple solutions to this problem. It can be resolved by directly optimizing in IR (llvm/llvm-project#95919) or during the code generation phase (llvm/llvm-project#95921). I believe the code generation phase is the key point, and we can use undef to eliminate this branch. However, I am more familiar with IR-related aspects, so let me resolve it here now.

[DianQK]

Fixed by llvm/llvm-project#95919.
@rustbot label +llvm-fixed-upstream
@rustbot claim

[nikic]

Confirmed fixed by #127513, needs codegen test.

[Skgland]

I just stumbled past this and am confused by the comment

(a % b) * 2 can not overflow since b >= 2

I would expect this to overflow if a > u64::MAX / 2 and b > a (playground)

[mickvangelderen]

I would expect this to overflow if a > u64::MAX / 2 and b > a (playground)

You're right, I made a logical error.