From a27f3e3fd1e4d16160f8885b6b06665b5319f56c Mon Sep 17 00:00:00 2001
From: Guillaume Gomez <guillaume1.gomez@gmail.com>
Date: Mon, 21 Jul 2025 14:34:12 +0200
Subject: Rename `tests/codegen` into `tests/codegen-llvm`

---
 tests/codegen/array-map.rs | 35 -----------------------------------
 1 file changed, 35 deletions(-)
 delete mode 100644 tests/codegen/array-map.rs

(limited to 'tests/codegen/array-map.rs')

diff --git a/tests/codegen/array-map.rs b/tests/codegen/array-map.rs
deleted file mode 100644
index f49dddcfc20..00000000000
--- a/tests/codegen/array-map.rs
+++ /dev/null
@@ -1,35 +0,0 @@
-//@ compile-flags: -C opt-level=3 -C target-cpu=x86-64-v3
-//@ only-x86_64
-
-#![crate_type = "lib"]
-
-// CHECK-LABEL: @short_integer_map
-#[no_mangle]
-pub fn short_integer_map(x: [u32; 8]) -> [u32; 8] {
-    // CHECK: load <8 x i32>
-    // CHECK: shl <8 x i32>
-    // CHECK: or{{( disjoint)?}} <8 x i32>
-    // CHECK: store <8 x i32>
-    x.map(|x| 2 * x + 1)
-}
-
-// This test is checking that LLVM can SRoA away a bunch of the overhead,
-// like fully moving the iterators to registers.  Notably, previous implementations
-// of `map` ended up `alloca`ing the whole `array::IntoIterator`, meaning both a
-// hard-to-eliminate `memcpy` and that the iteration counts needed to be written
-// out to stack every iteration, even for infallible operations on `Copy` types.
-//
-// This is still imperfect, as there's more copies than would be ideal,
-// but hopefully work like #103830 will improve that in future,
-// and update this test to be stricter.
-//
-// CHECK-LABEL: @long_integer_map
-#[no_mangle]
-pub fn long_integer_map(x: [u32; 512]) -> [u32; 512] {
-    // CHECK: start:
-    // CHECK-NEXT: alloca [2048 x i8]
-    // CHECK-NOT: alloca
-    // CHECK: mul <{{[0-9]+}} x i32>
-    // CHECK: add <{{[0-9]+}} x i32>
-    x.map(|x| 13 * x + 7)
-}
-- 
cgit 1.4.1-3-g733a5