File: array-map.rs

package info (click to toggle)
rustc 1.85.0%2Bdfsg3-1
  • links: PTS, VCS
  • area: main
  • in suites: experimental, sid, trixie
  • size: 893,396 kB
  • sloc: xml: 158,127; python: 35,830; javascript: 19,497; cpp: 19,002; sh: 17,245; ansic: 13,127; asm: 4,376; makefile: 1,051; perl: 29; lisp: 29; ruby: 19; sql: 11
file content (35 lines) | stat: -rw-r--r-- 1,228 bytes parent folder | download | duplicates (3)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
//@ 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)
}