Type Definition packed_simd_2::mptrx2
source · [−]Expand description
A vector with 2 *mut T
lanes
Implementations
Creates a new instance with each vector elements initialized with the provided values.
Constructs a new instance with each element initialized to
value
.
Returns a mask that selects those lanes that contain null
pointers.
Returns a new vector where the value at index
is replaced by
new_value
.
Panics
If index >= Self::lanes()
.
Returns a new vector where the value at index
is replaced by new_value
.
Safety
If index >= Self::lanes()
the behavior is undefined.
Instantiates a new vector with the values of the slice
.
Panics
If slice.len() < Self::lanes()
or &slice[0]
is not aligned
to an align_of::<Self>()
boundary.
Instantiates a new vector with the values of the slice
.
Safety
If slice.len() < Self::lanes()
or &slice[0]
is not aligned
to an align_of::<Self>()
boundary, the behavior is undefined.
Writes the values of the vector to the slice
.
Panics
If slice.len() < Self::lanes()
or &slice[0]
is not
aligned to an align_of::<Self>()
boundary.
Writes the values of the vector to the slice
.
Safety
If slice.len() < Self::lanes()
or &slice[0]
is not
aligned to an align_of::<Self>()
boundary, the behavior is
undefined.
Calculates the offset from a pointer.
count
is in units of T
; e.g. a count of 3
represents a
pointer offset of 3 * size_of::<T>()
bytes.
Safety
If any of the following conditions are violated, the result is Undefined Behavior:
-
Both the starting and resulting pointer must be either in bounds or one byte past the end of an allocated object.
-
The computed offset, in bytes, cannot overflow an
isize
. -
The offset being in bounds cannot rely on “wrapping around” the address space. That is, the infinite-precision sum, in bytes must fit in a
usize
.
The compiler and standard library generally tries to ensure
allocations never reach a size where an offset is a concern. For
instance, Vec
and Box
ensure they never allocate more than
isize::MAX
bytes, so vec.as_ptr().offset(vec.len() as isize)
is always safe.
Most platforms fundamentally can’t even construct such an
allocation. For instance, no known 64-bit platform can ever
serve a request for 263 bytes due to page-table limitations or
splitting the address space. However, some 32-bit and 16-bit
platforms may successfully serve a request for more than
isize::MAX
bytes with things like Physical Address Extension.
As such, memory acquired directly from allocators or memory
mapped files may be too large to handle with this function.
Consider using wrapping_offset
instead if these constraints
are difficult to satisfy. The only advantage of this method is
that it enables more aggressive compiler optimizations.
Calculates the offset from a pointer using wrapping arithmetic.
count
is in units of T
; e.g. a count of 3
represents a
pointer offset of 3 * size_of::<T>()
bytes.
Safety
The resulting pointer does not need to be in bounds, but it is potentially hazardous to dereference (which requires unsafe).
Always use .offset(count)
instead when possible, because
offset allows the compiler to optimize better.
Calculates the distance between two pointers.
The returned value is in units of T
: the distance in bytes is
divided by mem::size_of::<T>()
.
This function is the inverse of offset.
Safety
If any of the following conditions are violated, the result is Undefined Behavior:
-
Both the starting and other pointer must be either in bounds or one byte past the end of the same allocated object.
-
The distance between the pointers, in bytes, cannot overflow an
isize
. -
The distance between the pointers, in bytes, must be an exact multiple of the size of
T
. -
The distance being in bounds cannot rely on “wrapping around” the address space.
The compiler and standard library generally try to ensure
allocations never reach a size where an offset is a concern. For
instance, Vec
and Box
ensure they never allocate more than
isize::MAX
bytes, so ptr_into_vec.offset_from(vec.as_ptr())
is always safe.
Most platforms fundamentally can’t even construct such an
allocation. For instance, no known 64-bit platform can ever
serve a request for 263 bytes due to page-table limitations or
splitting the address space. However, some 32-bit and 16-bit
platforms may successfully serve a request for more than
isize::MAX
bytes with things like Physical Address Extension.
As such, memory acquired directly from allocators or memory
mapped files may be too large to handle with this function.
Consider using wrapping_offset_from
instead if these constraints
are difficult to satisfy. The only advantage of this method is
that it enables more aggressive compiler optimizations.
Calculates the distance between two pointers.
The returned value is in units of T
: the distance in bytes is
divided by mem::size_of::<T>()
.
If the address different between the two pointers is not a
multiple of mem::size_of::<T>()
then the result of the
division is rounded towards zero.
Though this method is safe for any two pointers, note that its result will be mostly useless if the two pointers aren’t into the same allocated object, for example if they point to two different local variables.
Calculates the offset from a pointer (convenience for
.offset(count as isize)
).
count
is in units of T
; e.g. a count of 3 represents a
pointer offset of 3 * size_of::<T>()
bytes.
Safety
If any of the following conditions are violated, the result is Undefined Behavior:
-
Both the starting and resulting pointer must be either in bounds or one byte past the end of an allocated object.
-
The computed offset, in bytes, cannot overflow an
isize
. -
The offset being in bounds cannot rely on “wrapping around” the address space. That is, the infinite-precision sum must fit in a
usize
.
The compiler and standard library generally tries to ensure
allocations never reach a size where an offset is a concern. For
instance, Vec
and Box
ensure they never allocate more than
isize::MAX
bytes, so vec.as_ptr().add(vec.len())
is always
safe.
Most platforms fundamentally can’t even construct such an
allocation. For instance, no known 64-bit platform can ever
serve a request for 263 bytes due to page-table limitations or
splitting the address space. However, some 32-bit and 16-bit
platforms may successfully serve a request for more than
isize::MAX
bytes with things like Physical Address Extension.
As such, memory acquired directly from allocators or memory
mapped files may be too large to handle with this function.
Consider using wrapping_offset
instead if these constraints
are difficult to satisfy. The only advantage of this method is
that it enables more aggressive compiler optimizations.
Calculates the offset from a pointer (convenience for
.offset((count as isize).wrapping_neg())
).
count
is in units of T; e.g. a count
of 3 represents a
pointer offset of 3 * size_of::<T>()
bytes.
Safety
If any of the following conditions are violated, the result is Undefined Behavior:
-
Both the starting and resulting pointer must be either in bounds or one byte past the end of an allocated object.
-
The computed offset cannot exceed
isize::MAX
bytes. -
The offset being in bounds cannot rely on “wrapping around” the address space. That is, the infinite-precision sum must fit in a usize.
The compiler and standard library generally tries to ensure
allocations never reach a size where an offset is a concern. For
instance, Vec
and Box
ensure they never allocate more than
isize::MAX
bytes, so
vec.as_ptr().add(vec.len()).sub(vec.len())
is always safe.
Most platforms fundamentally can’t even construct such an
allocation. For instance, no known 64-bit platform can ever
serve a request for 263 bytes due to page-table
limitations or splitting the address space. However, some 32-bit
and 16-bit platforms may successfully serve a request for more
than isize::MAX
bytes with things like Physical Address
Extension. As such, memory acquired directly from allocators or
memory mapped files may be too large to handle with this
function.
Consider using wrapping_offset
instead if these constraints
are difficult to satisfy. The only advantage of this method is
that it enables more aggressive compiler optimizations.
Calculates the offset from a pointer using wrapping arithmetic.
(convenience for .wrapping_offset(count as isize)
)
count
is in units of T; e.g. a count
of 3 represents a
pointer offset of 3 * size_of::<T>()
bytes.
Safety
The resulting pointer does not need to be in bounds, but it is
potentially hazardous to dereference (which requires unsafe
).
Always use .add(count)
instead when possible, because add
allows the compiler to optimize better.
Calculates the offset from a pointer using wrapping arithmetic.
(convenience for .wrapping_offset((count as isize).wrapping_sub())
)
count
is in units of T; e.g. a count
of 3 represents a
pointer offset of 3 * size_of::<T>()
bytes.
Safety
The resulting pointer does not need to be in bounds, but it is
potentially hazardous to dereference (which requires unsafe
).
Always use .sub(count)
instead when possible, because sub
allows the compiler to optimize better.
Shuffle vector elements according to indices
.
Reads selected vector elements from memory.
Instantiates a new vector by reading the values from self
for
those lanes whose mask
is true
, and using the elements of
value
otherwise.
No memory is accessed for those lanes of self
whose mask
is
false
.
Safety
This method is unsafe because it dereferences raw pointers. The
pointers must be aligned to mem::align_of::<T>()
.
Writes selected vector elements to memory.
Writes the lanes of values
for which the mask is true
to
their corresponding memory addresses in self
.
No memory is accessed for those lanes of self
whose mask
is
false
.
Overlapping memory addresses of self
are written to in order
from the lest-significant to the most-significant element.
Safety
This method is unsafe because it dereferences raw pointers. The
pointers must be aligned to mem::align_of::<T>()
.