Codegen regression of indexing of slice on nightly

[CrazyboyQCD]

Not sure if it is related with LLVM.
https://godbolt.org/z/vhKoWYxM5

#[inline(never)]
pub fn f_index(data: &mut [u32]) {
    for i in 0..data.len() {
        data[i] += 1;
    }
}

Regression part in LBB0_4:

stable:

        mov     rax, rsi
        and     rax, -8
        xor     ecx, ecx
        pcmpeqd xmm0, xmm0

nightly:

        movabs  rax, 2305843009213693944
        and     rax, rsi
        lea     rcx, [4*rsi]
        and     rcx, -32
        xor     edx, edx
        pcmpeqd xmm0, xmm0

[nikic]

Could you please clarify what regression you're referring to? Is this about the replacement of the and -8 with a larger immediate or something else?

[CrazyboyQCD]

Could you please clarify what regression you're referring to? Is this about the replacement of the and -8 with a larger immediate or something else?

Sure, regression part is added.

[SpriteOvO]

Bisection points to #148350.

[apiraino]

In #148350 I see a discussion about the perf. results (in the end accepted), I don't know if this issue is relevant to that.

cc @davidtwco @JonathanBrouwer @scottmcm

thanks

[JonathanBrouwer]

This is the difference in the generated LLVM IR with and without this optimization, generated using:

rustc +stage1 --emit=llvm-ir -C opt-level=2 src/lib.rs 

For the following code

#![crate_type = "lib"]

#[no_mangle]
#[inline(never)]
pub fn f_index(data: &mut [u32]) {
    for i in 0..data.len() {
        data[i] += 1;
    }
}

On the left without the change from the PR, on the right with the change from the PR (current develop)
https://www.diffchecker.com/TH7c8YwH/

I am not that experienced reading LLVM IR, but to me it seems like the new code has more hints for LLVM, other than that the are no differences

[JonathanBrouwer]

Actually it might be that the and instruction generated optimizes worse by LLVM.
Without the change from the PR rust generates an AND with 0xFFFFFFFFFFFFFFF8, with the change from the PR rust generates an AND with 1FFFFFFFFFFFFFF8. Both are correct (because the leading bits are always zero), but the second is not optimized as well by LLVM

[JonathanBrouwer]

Not entirely sure what to do with this observation, I guess we can consider reverting the original PR since it didn't have a significant perf win anyways?