To implement FastLanes, I'm defining a 1024-bit simd vector type. This is quite easy to do with something like:
#[repr(C, align(64))]
struct Chunk(u64x8, u64x8);
To implement stuff like as_slice on this, I can unsafely convert &self to a &[u8] of the correct length, because u64x8 is also repr(C) and the alignment guarantees that there's no padding.
But afaict fearless_simd doesn't currently promise anything about the layout of these types, so I can't be certain that it'll keep working in future (although it seems unlikely to change). Could fearless_simd document some guarantees about those types? Maybe something like this, for all SimdBase types:
size_of::<T>() == size_of::<T::Array>()
align_of::<T>() >= align_of::<T::Element>() (codegen currently makes this == on the published type, but I think the arch-specific intrinsic types inside might force larger alignment on some platforms?)
To implement FastLanes, I'm defining a 1024-bit simd vector type. This is quite easy to do with something like:
To implement stuff like
as_sliceon this, I can unsafely convert &self to a &[u8] of the correct length, because u64x8 is also repr(C) and the alignment guarantees that there's no padding.But afaict fearless_simd doesn't currently promise anything about the layout of these types, so I can't be certain that it'll keep working in future (although it seems unlikely to change). Could fearless_simd document some guarantees about those types? Maybe something like this, for all SimdBase types:
size_of::<T>() == size_of::<T::Array>()align_of::<T>() >= align_of::<T::Element>()(codegen currently makes this==on the published type, but I think the arch-specific intrinsic types inside might force larger alignment on some platforms?)