types.rs - source
Description: Source of the Rust file `library/core/src/../../stdarch/crates/core_arch/src/loongarch64/lasx/types.rs`.

#
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;