Auto merge of #139430 - scottmcm:polymorphic-array-into-iter, r=cuviper

Polymorphize `array::IntoIter`'s iterator impl

Today we emit all the iterator methods for every different array width.  That's wasteful since the actual array length never even comes into it -- the indices used are from the separate `alive: IndexRange` field, not even the `N` const param.

This PR switches things so that an `array::IntoIter<T, N>` stores a `PolymorphicIter<[MaybeUninit<T>; N]>`, which we *unsize* to `PolymorphicIter<[MaybeUninit<T>]>` and call methods on that non-`Sized` type for all the iterator methods.

That also necessarily makes the layout consistent between the different lengths of arrays, because of the unsizing.  Compare that to today <https://rust.godbolt.org/z/Prb4xMPrb>, where different widths can't even be deduped because the offset to the indices is different for different array widths.

1 files changed, 32 insertions, 3 deletions

diff --git a/tests/codegen/issues/issue-101082.rs b/tests/codegen/issues/issue-101082.rs
index 7fb850ca253..96cdff64dda 100644
--- a/tests/codegen/issues/issue-101082.rs
+++ b/tests/codegen/issues/issue-101082.rs
@@ -1,8 +1,16 @@
 //@ compile-flags: -Copt-level=3
-//@ revisions: host x86-64-v3
+//@ revisions: host x86-64 x86-64-v3
 //@ min-llvm-version: 20
 
-// This particular CPU regressed in #131563
+//@[host] ignore-x86_64
+
+// Set the base cpu explicitly, in case the default has been changed.
+//@[x86-64] only-x86_64
+//@[x86-64] compile-flags: -Ctarget-cpu=x86-64
+
+// FIXME(cuviper) x86-64-v3 in particular regressed in #131563, and the workaround
+// at the time still sometimes fails, so only verify it for the power-of-two size
+// - https://github.com/llvm/llvm-project/issues/134735
 //@[x86-64-v3] only-x86_64
 //@[x86-64-v3] compile-flags: -Ctarget-cpu=x86-64-v3
 
@@ -11,7 +19,16 @@
 #[no_mangle]
 pub fn test() -> usize {
     // CHECK-LABEL: @test(
-    // CHECK: ret {{i64|i32}} 165
+    // host: ret {{i64|i32}} 165
+    // x86-64: ret {{i64|i32}} 165
+
+    // FIXME: Now that this autovectorizes via a masked load, it doesn't actually
+    // const-fold for certain widths.  The `test_eight` case below shows that, yes,
+    // what we're emitting *can* be const-folded, except that the way LLVM does it
+    // for certain widths doesn't today.  We should be able to put this back to
+    // the same check after <https://github.com/llvm/llvm-project/issues/134513>
+    // x86-64-v3: masked.load
+
     let values = [23, 16, 54, 3, 60, 9];
     let mut acc = 0;
     for item in values {
@@ -19,3 +36,15 @@ pub fn test() -> usize {
     }
     acc
 }
+
+#[no_mangle]
+pub fn test_eight() -> usize {
+    // CHECK-LABEL: @test_eight(
+    // CHECK: ret {{i64|i32}} 220
+    let values = [23, 16, 54, 3, 60, 9, 13, 42];
+    let mut acc = 0;
+    for item in values {
+        acc += item;
+    }
+    acc
+}