Codegen regression of indexing of slice on nightly

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

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?

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.

Bisection points to #148350.

@davidtwco

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

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

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

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?

@rustbot

Assigning priority (discussion on Zulip).

@rustbot label -I-prioritize +P-medium +regression-from-stable-to-beta

If you look at what we actually give to LLVM https://godbolt.org/z/9ddzW74s4 (rather than the post-optimization IR), you'll see that the only meaningful difference is having the range(i64 0, 2305843009213693952) attribute on %data.1.

Any change to the constant being anded is entirely something that LLVM did, so I think this should just be reported to LLVM. (Obviously it's not intentionally producing worse output given a more-constrained input.)

Also, importantly note that this difference isn't in the loop body. It's just a couple pipelined instructions in the preheader for vectorization. If the slice is shorter than 8, the section with the difference doesn't run. And if it's 8-or-more, the inner loop is still

.LBB0_5:
        movdqu  xmm1, xmmword ptr [rdi + 4*rcx]
        movdqu  xmm2, xmmword ptr [rdi + 4*rcx + 16]
        psubd   xmm1, xmm0
        psubd   xmm2, xmm0
        movdqu  xmmword ptr [rdi + 4*rcx], xmm1
        movdqu  xmmword ptr [rdi + 4*rcx + 16], xmm2
        add     rcx, 8
        cmp     rax, rcx
        jne     .LBB0_5

so IMHO this would be more P-low, not even P-medium, unless people can show more concrete impact from it.

I don't think we should revert it because that also loses the places where LLVM takes better advantage of the parameter range, like in getting more samesign and nsw flags on other instructions that then enable other downstream optimizations.

(If this was impact to the inner loop, or to ever indexing, or something then I'd be far more worried, but here I'm not and it's just something for LLVM to eventually handle in a smarter way.)

@rustbot

Upstream: llvm/llvm-project#196786

@rustbot claim

Navigation Menu

Repository navigation

Codegen regression of indexing of slice on nightly #149673

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Codegen regression of indexing of slice on nightly #149673

Description

Activity

nikic commented on Dec 5, 2025

CrazyboyQCD commented on Dec 5, 2025

SpriteOvO commented on Jan 22, 2026

apiraino commented on Jan 29, 2026

JonathanBrouwer commented on Jan 30, 2026

JonathanBrouwer commented on Jan 30, 2026

JonathanBrouwer commented on Jan 30, 2026

apiraino commented on Feb 5, 2026

scottmcm commented on Feb 5, 2026

el-ev commented on May 10, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions