split_at fails to optimize bounds check

[lcnr]

https://rust.godbolt.org/z/E1PnPj

const N: usize = 3;
const T = u8;

pub fn split_mutiple(slice: &[T]) -> (&[T], &[T]) {
    let len = slice.len() / N;
    slice.split_at(len * N)
}

results in the following assembly

example::split_mutiple:
        push    rax
        mov     r8, rdx
        mov     rcx, rdi
        movabs  rdx, -6148914691236517205
        mov     rax, r8
        mul     rdx
        shr     rdx
        lea     rdx, [rdx + 2*rdx]
        mov     rax, r8
        sub     rax, rdx
        mov     rdi, r8
        sub     rdi, rax
        jb      .LBB0_1  ; Note that this check can never be actually hit
        mov     qword ptr [rcx], rsi
        add     rsi, rdi
        mov     qword ptr [rcx + 8], rdi
        mov     qword ptr [rcx + 16], rsi
        mov     qword ptr [rcx + 24], rax
        mov     rax, rcx
        pop     rcx
        ret
.LBB0_1:
        lea     rdx, [rip + .L__unnamed_1]
        mov     rsi, r8
        call    qword ptr [rip + core::slice::slice_index_len_fail@GOTPCREL]
        ud2

When using const N: usize = 4 the check is correctly optimized away:

example::split_mutiple:
        mov     rax, rdi
        mov     rcx, rdx
        and     rcx, -4
        and     edx, 3
        mov     qword ptr [rdi], rsi
        add     rsi, rcx
        mov     qword ptr [rdi + 8], rcx
        mov     qword ptr [rdi + 16], rsi
        mov     qword ptr [rdi + 24], rdx
        ret

This happens both on all stable versions I have tested and on the most recent nightly.

[bugadani]

In fact, this has nothing to do with slices: https://rust.godbolt.org/z/7oG6qE change from 3 to 4 (or other powers of 2) to see everything optimized away.

Edit: reduced it some more: https://rust.godbolt.org/z/bEoj8x

[tesuji]

There are no optimization in GCC and Clang either: https://godbolt.org/z/M88ndP

#include <stddef.h>

const size_t N = 3;

int foo(size_t len) {
	size_t newlen = (len / N) * N;
	return newlen <= len;
}

Should foo be optimized to only return true?

[tesuji]

So this is more as LLVM part: @rustbot modify labels: +A-LLVM +A-mir-opt
Of course this might be improved with MIR-opt. But how hard it would be? I don't know.

[bugadani]

So this is more as LLVM part

What's interesting is that the power of 2 optimization is done by rustc somewhere - the same MIR is translated to radically different LLVM-IR when N is 2^n.

Trying to find where this happens without knowledge of the compiler is rather difficult, though :)

[tesuji]

Clang could do that, change N=4 in my snippet about to see. But still GCC doesn't do that.

[nikic]

https://github.com/llvm/llvm-project/blob/63d3aeb529a7b0fb95c2092ca38ad21c1f5cfd74/llvm/lib/Transforms/InstCombine/InstCombineMulDivRem.cpp#L311 needs to set a nuw flag. Then it will probably fold.

[bugadani]

Cool. So if I understand correctly, the following is happening:

The bounds check boils down to basically (length / N) * N <= length.
This can be transformed to length - length % N <= length (fair enough)
This is further transformed to (as the llvm ir shows) length % N <= length; (I don't see how this transform is equivalent, but OK)

And for some reason, LLVM can't seem to deduce that this comparison will always be false. Adding this as an assumption will make the check be optimized:

https://rust.godbolt.org/z/vM1KPM

[xldenis]

@bugadani, what's weird is that if you feed this IR straight into llc it does optimize it away: https://rust.godbolt.org/z/o6d6nM. Are we not calling a magic pass on the IR in rustc?

Ignore me, I missed that the assume caused the IR to have ret true

However, it does optimize if a udiv is inserted instead of a urem, InstructionSimplify has the following opt: x udiv y <=u x I don't know why the same doesn't exist for urem? maybe no one considered it until now?

LLVM doesn't know about this optimization but it is apparently valid (thanks John Regehr) so I'll submit a patch to LLVM.

[xldenis]

I've submitted a patch to LLVM adding this optimization: https://reviews.llvm.org/D85092

[tesuji]

Does anyone want to file a bug against GCC? I registered an account two days ago but they hasn't accepted my account yet.

[xldenis]

^ as you can see above this optimization has landed in LLVM master, so whenever LLVM is bumped we should get this for free.

[tesuji]

Does it land with LLVM 11?

[xldenis]

it's not in RC-1 which was released a week ago, I don't know if they will include it in a future release candidate or not.

[xldenis]

This will be solved in LLVM 12 as my commit missed the cutoff (it was before the issue was even filed)

[jrmuizel]

I filed the gcc bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97529

[jrmuizel]

I confirmed that with #81451 the bounds check is removed.

[xldenis]

Can we close this issue?

[mati865]

@lcnr could you test again and close this issue?

[lcnr]

this has been fixed, would be nice to add a codegen test for this, asserting that split_multiple can't panic