Regression: `tests/codegen/issues/issue-101082.rs` fails with `-Ctarget-cpu=x86-64-v3`

Code

I tried this test with -Ctarget-cpu=x86-64-v3 (which we have on by default in the upcoming RHEL 10):

tests/codegen/issues/issue-101082.rs

//@ compile-flags: -O

#![crate_type = "lib"]

#[no_mangle]
pub fn test() -> usize {
    // CHECK-LABEL: @test(
    // CHECK: ret {{i64|i32}} 165
    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: FileCheck pass

Instead, this happened:

issue-101082.rs:8:12: error: CHECK: expected string not found in input

As of rustc 1.83.0-nightly (52fd99839 2024-10-10), that LLVM IR is:

; Function Attrs: nofree norecurse nosync nounwind nonlazybind memory(inaccessiblemem: write) uwtable
define noundef i64 @test() unnamed_addr #0 personality ptr @rust_eh_personality {
start:
  %iter = alloca [64 x i8], align 8
  call void @llvm.lifetime.start.p0(i64 64, ptr nonnull %iter)
  store i64 23, ptr %iter, align 8
  %_3.sroa.0.sroa.4.0.iter.sroa_idx = getelementptr inbounds i8, ptr %iter, i64 8
  store i64 16, ptr %_3.sroa.0.sroa.4.0.iter.sroa_idx, align 8
  %_3.sroa.0.sroa.5.0.iter.sroa_idx = getelementptr inbounds i8, ptr %iter, i64 16
  store i64 54, ptr %_3.sroa.0.sroa.5.0.iter.sroa_idx, align 8
  %_3.sroa.0.sroa.6.0.iter.sroa_idx = getelementptr inbounds i8, ptr %iter, i64 24
  store i64 3, ptr %_3.sroa.0.sroa.6.0.iter.sroa_idx, align 8
  %_3.sroa.0.sroa.7.0.iter.sroa_idx = getelementptr inbounds i8, ptr %iter, i64 32
  store i64 60, ptr %_3.sroa.0.sroa.7.0.iter.sroa_idx, align 8
  %_3.sroa.0.sroa.8.0.iter.sroa_idx = getelementptr inbounds i8, ptr %iter, i64 40
  store i64 9, ptr %_3.sroa.0.sroa.8.0.iter.sroa_idx, align 8
  %unmaskedload = load <4 x i64>, ptr %iter, align 8, !alias.scope !3
  %0 = getelementptr inbounds i8, ptr %iter, i64 32
  %unmaskedload10 = load <4 x i64>, ptr %0, align 8, !alias.scope !3
  %1 = add <4 x i64> %unmaskedload10, %unmaskedload
  %2 = shufflevector <4 x i64> %1, <4 x i64> %unmaskedload, <4 x i32> <i32 0, i32 1, i32 6, i32 7>
  %3 = tail call i64 @llvm.vector.reduce.add.v4i64(<4 x i64> %2)
  call void @llvm.lifetime.end.p0(i64 64, ptr nonnull %iter)
  ret i64 %3
}

Reducing to x86-64-v2 does get the expected output:

; Function Attrs: nofree norecurse nosync nounwind nonlazybind memory(inaccessiblemem: write) uwtable
define noundef i64 @test() unnamed_addr #0 personality ptr @rust_eh_personality {
start:
  ret i64 165
}

Version it worked on

It most recently worked on: Rust 1.79.0

Version with regression

rustc --version --verbose:

rustc 1.80.0 (051478957 2024-07-21)
binary: rustc
commit-hash: 051478957371ee0084a7c0913941d2a8c4757bb9
commit-date: 2024-07-21
host: x86_64-unknown-linux-gnu
release: 1.80.0
LLVM version: 18.1.7

Note that the original issue #101082 was fixed by an LLVM upgrade. That version didn't change between 1.79.0 and 1.80.0, but there were some additional cherry-picks: https://github.com/rust-lang/llvm-project/compare/rustc-1.79.0...rustc-1.80.0

However, cargo-bisect-rustc narrowed down to something else.

Bisection

searched nightlies: from nightly-2024-04-28 to nightly-2024-10-11
regressed nightly: nightly-2024-05-26
searched commit range: https://github.com/rust-lang/rust/compare/36153f1a4e3162f0a143c7b3e468ecb3beb0008e...1ba35e9bb44d416fc2ebf897855454258b650b01
regressed commit: https://github.com/rust-lang/rust/commit/48f00110d0dae38b3046a9ac05d20ea321fd6637 (#121571)

cargo bisect-rustc --script test.sh --start 1.79.0

#!/bin/sh
rustc --emit=llvm-ir -O -Ctarget-cpu=x86-64-v3 -o- issue-101082.rs | FileCheck issue-101082.rs

@rustbot modify labels: +A-codegen +regression-from-stable-to-stable -regression-untriaged

Start with tests/codegen/issues/issue-101082.rs and reproduce the failure using the issue's test.sh command with -Ctarget-cpu=x86-64-v3. Then inspect the bisected commit #121571 and compare the generated LLVM IR with x86-64-v2. Done means the FileCheck test passes for x86-64-v3 while preserving the expected behavior for the existing case.