core/stdarch/crates/core_arch/src/loongarch64/lasx/types.rs
1types! {
2 #![unstable(feature = "stdarch_loongarch", issue = "117427")]
3
4 /// 256-bit wide integer vector type, LoongArch-specific
5 ///
6 /// This type is the same as the `__m256i` type defined in `lasxintrin.h`,
7 /// representing a 256-bit SIMD register. Usage of this type typically
8 /// occurs in conjunction with the `lasx` target features for LoongArch.
9 ///
10 /// Internally this type may be viewed as:
11 ///
12 /// * `i8x32` - thirty two `i8` values packed together
13 /// * `i16x16` - sixteen `i16` values packed together
14 /// * `i32x8` - eight `i32` values packed together
15 /// * `i64x4` - four `i64` values packed together
16 ///
17 /// (as well as unsigned versions). Each intrinsic may interpret the
18 /// internal bits differently, check the documentation of the intrinsic
19 /// to see how it's being used.
20 ///
21 /// The in-memory representation of this type is the same as the one of an
22 /// equivalent array (i.e. the in-memory order of elements is the same, and
23 /// there is no padding); however, the alignment is different and equal to
24 /// the size of the type. Note that the ABI for function calls may *not* be
25 /// the same.
26 ///
27 /// Note that this means that an instance of `m256i` typically just means
28 /// a "bag of bits" which is left up to interpretation at the point of use.
29 ///
30 /// Most intrinsics using `m256i` are prefixed with `lasx_` and the integer
31 /// types tend to correspond to suffixes like "b", "h", "w" or "d".
32 pub struct m256i(4 x i64);
33
34 /// 256-bit wide set of eight `f32` values, LoongArch-specific
35 ///
36 /// This type is the same as the `__m256` type defined in `lasxintrin.h`,
37 /// representing a 256-bit SIMD register which internally consists of
38 /// eight packed `f32` instances. Usage of this type typically occurs in
39 /// conjunction with the `lasx` target features for LoongArch.
40 ///
41 /// Note that unlike `m256i`, the integer version of the 256-bit registers,
42 /// this `m256` type has *one* interpretation. Each instance of `m256`
43 /// always corresponds to `f32x8`, or eight `f32` values packed together.
44 ///
45 /// The in-memory representation of this type is the same as the one of an
46 /// equivalent array (i.e. the in-memory order of elements is the same, and
47 /// there is no padding between two consecutive elements); however, the
48 /// alignment is different and equal to the size of the type. Note that the
49 /// ABI for function calls may *not* be the same.
50 ///
51 /// Most intrinsics using `m256` are prefixed with `lasx_` and are
52 /// suffixed with "s".
53 pub struct m256(8 x f32);
54
55 /// 256-bit wide set of four `f64` values, LoongArch-specific
56 ///
57 /// This type is the same as the `__m256d` type defined in `lasxintrin.h`,
58 /// representing a 256-bit SIMD register which internally consists of
59 /// four packed `f64` instances. Usage of this type typically occurs in
60 /// conjunction with the `lasx` target features for LoongArch.
61 ///
62 /// Note that unlike `m256i`, the integer version of the 256-bit registers,
63 /// this `m256d` type has *one* interpretation. Each instance of `m256d`
64 /// always corresponds to `f64x4`, or four `f64` values packed together.
65 ///
66 /// The in-memory representation of this type is the same as the one of an
67 /// equivalent array (i.e. the in-memory order of elements is the same, and
68 /// there is no padding); however, the alignment is different and equal to
69 /// the size of the type. Note that the ABI for function calls may *not* be
70 /// the same.
71 ///
72 /// Most intrinsics using `m256d` are prefixed with `lasx_` and are suffixed
73 /// with "d". Not to be confused with "d" which is used for `m256i`.
74 pub struct m256d(4 x f64);
75
76}
77
78#[allow(non_camel_case_types)]
79#[repr(simd)]
80pub(crate) struct __v32i8([i8; 32]);
81#[allow(non_camel_case_types)]
82#[repr(simd)]
83pub(crate) struct __v16i16([i16; 16]);
84#[allow(non_camel_case_types)]
85#[repr(simd)]
86pub(crate) struct __v8i32([i32; 8]);
87#[allow(non_camel_case_types)]
88#[repr(simd)]
89pub(crate) struct __v4i64([i64; 4]);
90#[allow(non_camel_case_types)]
91#[repr(simd)]
92pub(crate) struct __v32u8([u8; 32]);
93#[allow(non_camel_case_types)]
94#[repr(simd)]
95pub(crate) struct __v16u16([u16; 16]);
96#[allow(non_camel_case_types)]
97#[repr(simd)]
98pub(crate) struct __v8u32([u32; 8]);
99#[allow(non_camel_case_types)]
100#[repr(simd)]
101pub(crate) struct __v4u64([u64; 4]);
102#[allow(non_camel_case_types)]
103#[repr(simd)]
104pub(crate) struct __v8f32([f32; 8]);
105#[allow(non_camel_case_types)]
106#[repr(simd)]
107pub(crate) struct __v4f64([f64; 4]);
108
109// These type aliases are provided solely for transitional compatibility.
110// They are temporary and will be removed when appropriate.
111#[allow(non_camel_case_types)]
112#[unstable(feature = "stdarch_loongarch", issue = "117427")]
113pub type v32i8 = m256i;
114#[allow(non_camel_case_types)]
115#[unstable(feature = "stdarch_loongarch", issue = "117427")]
116pub type v16i16 = m256i;
117#[allow(non_camel_case_types)]
118#[unstable(feature = "stdarch_loongarch", issue = "117427")]
119pub type v8i32 = m256i;
120#[allow(non_camel_case_types)]
121#[unstable(feature = "stdarch_loongarch", issue = "117427")]
122pub type v4i64 = m256i;
123#[allow(non_camel_case_types)]
124#[unstable(feature = "stdarch_loongarch", issue = "117427")]
125pub type v32u8 = m256i;
126#[allow(non_camel_case_types)]
127#[unstable(feature = "stdarch_loongarch", issue = "117427")]
128pub type v16u16 = m256i;
129#[allow(non_camel_case_types)]
130#[unstable(feature = "stdarch_loongarch", issue = "117427")]
131pub type v8u32 = m256i;
132#[allow(non_camel_case_types)]
133#[unstable(feature = "stdarch_loongarch", issue = "117427")]
134pub type v4u64 = m256i;
135#[allow(non_camel_case_types)]
136#[unstable(feature = "stdarch_loongarch", issue = "117427")]
137pub type v8f32 = m256;
138#[allow(non_camel_case_types)]
139#[unstable(feature = "stdarch_loongarch", issue = "117427")]
140pub type v4f64 = m256d;