Possibly Missed Optimization

[brooklyn-1337]

This generates the following ASM. Godbolt

fn foo(i: i32) -> i64 {
    let i = i.abs() as i64;
    i + i
}

foo:
        mov     eax, edi
        neg     eax
        cmovs   eax, edi
        cdqe
        add     rax, rax
        ret

But, this generates the following ASM. Godbolt

fn foo(i: i32) -> i64 {
    i.abs() as i64 + i.abs() as i64
}

foo:
        mov     eax, edi
        neg     eax
        mov     ecx, edi
        cmovns  ecx, eax
        test    edi, edi
        cdqe
        mov     edx, edi
        cmovs   rdx, rax
        movsxd  rax, ecx
        add     rax, rdx
        ret

Doing a small reordering makes sure they compile down to same ASM. Godbolt

fn foo(i: i32) -> i64 {
    let i = i.abs() as i64;
    i + i
}

fn foo_other(i: i32) -> i64 {
    let i = i.abs();
    i as i64 + i as i64
}

foo:
        mov     eax, edi
        neg     eax
        cmovs   eax, edi
        cdqe
        add     rax, rax
        ret

foo_other = foo

Meta

rustc --version --verbose:

1.92.0

[ZhekaS]

Not sure if it is expected to be aware that u32::abs() is pure. If it isn't, then from it's perspective the code isn't semantically equivalent, that is abs() might have side-effects and two calls are different from one.

UPD:
FWIW, with opt-level=z it produces the "optimized" assembly: https://godbolt.org/z/qrYveY4MW

[kper]

It seems that the cdqe isn't required.

https://godbolt.org/z/87T6vePdv
https://zig.godbolt.org/z/b31EjeeqW

[ais523]

@kper:

It seems that the cdqe isn't required.

It is required. The code in the C and Zig programs you linked has a subtly different meaning from the Rust code being discussed in this thread.

The CDQE only matters if i.abs() is negative, which is something that you wouldn't normally expect from the output of abs. (On x86-64, the processor's normal/implicit behaviour is to do an implicit u32 to u64 cast whenever the program writes to the 32-bit register %eax and then tries to read the value back from its 64-bit version %rax. Using CDQE forces the cast to be done as signed rather than unsigned, so you get an i32 to i64 cast instead – that's the only difference between the code with and without the CDQE.)

In C (and apparently also Zig, although I don't know Zig well enough to tell), the compiler is allowed to assume that the output of abs is nonnegative. That happens because the one input that doesn't have a valid corresponding positive value – which Rust calls i32::MIN – is considered by C to be undefined behaviour to provide to abs. This means that in all defined C program executions that call abs, the optimizer can assume it returns a non-negative number and optimise on that basis, because the program is allowed to do anything if i32::MIN is supplied as an argument. So it does an unsigned cast, as this is shorter/faster than a signed cast would be and the number is knownt to already be non-negative.

However, in Rust with integer overflow checks turned off (the default in release mode), i32::MIN::abs() has defined behavior and returns i32::MIN, which is a negative number. This means that it needs to be cast to i32::MIN as i64, leading to a final return value of i32::MIN as i64 * 2. Without the CDQE, the function would return i32::MIN as u32 as i64 * 2 which is a different number (positive rather than negative), and thus omitting the CDQE would be a miscompile.

[kper]

ah I see
thank you for your detailed explanation, my apologies