Rust generates suboptimal code for x.div_euclid(2)

[KamilaBorowska]

I tried this code:

pub fn div2(a: i32) -> i32 {
    a.div_euclid(2)
}

I expected to see this happen:

After compiling to assembly with -C opt-level=3 to generate the following x86 assembly code.

div2:
        mov     eax, edi
        sar     eax
        ret

Instead, this happened:

div2:
        mov     eax, edi
        shr     eax, 31
        add     eax, edi
        sar     eax
        not     edi
        and     edi, -2147483647
        cmp     edi, 1
        sbb     eax, 0
        ret

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

[Urgau]

Those are not equivalent! (EDIT: was wrong, see below) div_euclid say it it will round towards negative infinity if self < 0; while self / 2 always rounds towards positive infinity.

A simple playground example with -7 proves that they do not return the same value:

fn main() {
    assert_eq!(
        (-7i32) / 2, // -3 
        (-7i32).div_euclid(2) // -4
    );
}

However if you use u32 (or any unsigned integer) you will get the expected assembly.

@rustbot labels -C-bug -needs-triage +C-discussion

[KamilaBorowska]

Those are not equivalent!

@Urgau I believe x.div_euclid(2) and x >> 1 (not to be confused with x / 2) are in fact equivalent, and Alive2 tells me that this optimization is valid (https://alive2.llvm.org/ce/z/YVeJvZ), albeit I tested it with i8 (testing with i32 gets a timeout).

x / 2 on the other hand compiles down to the following:

div2:
        mov     eax, edi
        shr     eax, 31
        add     eax, edi
        sar     eax
        ret

Note how the generated code adds sign bit, which is correct. x / 2 is not the same thing as x >> 1 specifically because it rounds towards 0, and not negative infinity.

[Jules-Bertholet]

@rustbot labels +C-bug +needs-triage -C-discussion I-heavy I-slow A-LLVM A-codegen T-compiler

[nikic]

LLVM issue: llvm/llvm-project#73622 Worth noting that the problem only occurs with 2, not other power of two constants.

[Urgau]

@Urgau I believe x.div_euclid(2) and x >> 1 (not to be confused with x / 2) are in fact equivalent, and Alive2 tells me that this optimization is valid (https://alive2.llvm.org/ce/z/YVeJvZ), albeit I tested it with i8 (testing with i32 gets a timeout).

My bad, I wrongly deduced that you meant x / 2 not x >> 1. I even checked under Alive2. 👀

[nikic]

Confirmed fixed by #120055, needs codegen test.