Regression: Inlined loops not fully evaluating with const-eable dependencies

[sno2]

I tried this code:

pub fn arr() -> usize {
  let values = [23, 16, 54, 3, 60, 9];
  let mut acc = 0;
  for item in values { 
    acc += item;
  }
  acc
}

I expected to see this happen: The loop should be inlined because values is const-known. For example, here is the generated assembly on Rust 1.63.0 (Godbolt) and Rust Beta (Godbolt):

example::arr:
        mov     eax, 165
        ret

Instead, this happened: On nightly, the loop is inlined. However, the entire function is not computed despite the stable and beta Rust inlining it. Here is the generated assembly on Nightly (Godbolt):

.LCPI0_0:
        .quad   23
        .quad   16
.LCPI0_1:
        .quad   54
        .quad   3
.LCPI0_2:
        .quad   60
        .quad   9
example::arr:
        sub     rsp, 72
        movaps  xmm0, xmmword ptr [rip + .LCPI0_0]
        movaps  xmmword ptr [rsp], xmm0
        movaps  xmm0, xmmword ptr [rip + .LCPI0_1]
        movaps  xmmword ptr [rsp + 16], xmm0
        movaps  xmm0, xmmword ptr [rip + .LCPI0_2]
        movaps  xmmword ptr [rsp + 32], xmm0
        mov     qword ptr [rsp + 56], 6
        xor     ecx, ecx
        xor     edx, edx
        jmp     .LBB0_1
.LBB0_3:
        lea     rdi, [rcx + 1]
        mov     qword ptr [rsp + 48], rdi
        mov     rdx, qword ptr [rsp + 8*rcx]
        mov     esi, 1
        mov     rcx, rdi
        add     rdx, rax
        test    rsi, rsi
        je      .LBB0_5
.LBB0_1:
        mov     rax, rdx
        cmp     rcx, 5
        jbe     .LBB0_3
        xor     esi, esi
        add     rdx, rax
        test    rsi, rsi
        jne     .LBB0_1
.LBB0_5:
        add     rsp, 72
        ret

Meta

n/a - disclosed at usages

Keywords: const inline loop, const loop, const loop not evaluated

Relevant discord thread: https://discord.com/channels/273534239310479360/592856094527848449/1013050670942793808

[Rageking8]

@rustbot label regression-from-stable-to-nightly

[steffahn]

@rustbot label I-slow

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-high t-compiler

[nikic]

Partial fix: llvm/llvm-project@43e7d9a This at least allows the loop to be unrolled, though it only gets fully constant folded in the backend.

[nikic]

  %_2.sroa.4.0.iter.sroa_idx = getelementptr inbounds i8, ptr %iter, i64 48
  store i64 0, ptr %_2.sroa.4.0.iter.sroa_idx, align 8
  %_2.sroa.5.0.iter.sroa_idx = getelementptr inbounds i8, ptr %iter, i64 56
  store i64 6, ptr %_2.sroa.5.0.iter.sroa_idx, align 8
  %self1.i = getelementptr inbounds %"core::array::iter::IntoIter<usize, 6>", ptr %iter, i64 0, i32 1
  %_4.i.i = getelementptr inbounds %"core::array::iter::IntoIter<usize, 6>", ptr %iter, i64 0, i32 1, i32 1
  %_4.val.i.i = load i64, ptr %_4.i.i, align 8, !alias.scope !2
  %0 = load i64, ptr %self1.i, align 8, !alias.scope !2

Oh my, if it isn't yet another casualty of LLVM's dumb typed GEP representation. This might get fixed by #98615 as well.

[nikic]

This turns out to be surprisingly tricky due to phase ordering issues. Even with canonical GEPs, the loop bounds only become known after full unrolling, by which point it is too late. I think the best shot at this would be to generalize LICM scalar promotion to perform load promotion in the presence of potentially aliasing loads. https://reviews.llvm.org/D133111 is preparation to move in that direction.

[nikic]

https://reviews.llvm.org/D133192 for improved LICM promotion. Still needs to be combined with canonical GEPs to work.

[pnkfelix]

@nikic what are your thoughts on this ticket? Your partial fix was merged, but the other LLVM changes have not.

Meanwhile, it seems like #98615 has stalled, but nikic r+'ed it apart from wanting a FIXME removed, does that sound right? (I went ahead and added a commit to remove the FIXME.) And its not clear whether #98615 would actually resolve this, is that correct?

[nikic]

@pnkfelix We need both #98615 and https://reviews.llvm.org/D133192 to fully resolve this, as far as I remember. We should probably land #98615 ASAP to give us a chance to address regressions from it in LLVM 16.

[nikic]

Fixed by the LLVM 16 upgrade.