Description
Currently the _m128i
and _m256i
are just type aliases for i8x16
and i8x32
:
/// 128-bit wide signed integer vector type
#[allow(non_camel_case_types)]
pub type __m128i = ::v128::i8x16;
/// 256-bit wide signed integer vector type
#[allow(non_camel_case_types)]
pub type __m256i = ::v256::i8x32;
These are the places that are currently using them (unless my grep-fu failed, please correct me if I am missing some):
-
Comparing strings where the input is reinterpreted as 1byte.8bytes, ... depending on a flag:
_mm_cmpistrm
: Compare packed strings_mm_cmpestri
: Compare packed strings- ... most of the intrinsics in the sse42 module.
-
Shift bytes:
_mm_slli_si128
: Shifta
left byimm8
bytes while shifting in zeros._mm_bslli_si128
: Shifta
left byimm8
bytes while shifting in zeros._mm_bsrli_si128
: Shifta
right byimm8
bytes while shifting in zeros._mm_srli_si128
: Shifta
right byimm8
bytes while shifting in zeros.
-
As raw bits
i1x128
/i1x256
:_mm_testz_si128
: Tests whether the specified bits in a 128-bit integer vector are all zeros._mm256_and_si256
: Compute the bitwise AND of 256 bits (representing integer data) ina
andb
._mm256_extractf128_si256
: Extract 128 bits (composed of integer data) froma
, selected withimm8
._mm_lddqu_si128
: Load 128-bits of integer data from unaligned memory.
Switching It makes sense for these functions to operate on generic __mm_cmpistrm
to use bytes explicitly, and rename __m128i
/__m256i
to i1x128
/i1x256
might make the library more consistent. I am not sure. I also haven't used __mm_cmpistrm
before so maybe I am wrong to think that bytes there make sense.__m128i
types because how these are interpreted by the function depends on the function arguments passed. The shift byte functions should, however, operate on bytes.
Whether we can implement an i1x128
repr(simd)
type in current Rust is a different topic (LLVM supports this, but we might need to "tweak" rustc to make it work).
Thoughts?
This discussion spawned in #212 .