I've been working on a generic integers RFC with the intention that in the future we can simply use those, but it might still be that rounding up significantly in raw size is in some cases still preferred, unfortunately.

true, e.g. on SVP64 all mask vectors being a single u64 internally (when LANES <= 64) is likely most efficient

And in the original AVX512 case mentioned, the plausible masks use hardware representation of a u16 and a u64 (even if they are logically much smaller at times), and anything else is a peculiar choice.

It's not the most important thing that it be exactly-so, however, I suspect, because kmovb also exists? Hmm.

Thanks everyone for the helpful comments.

Per Caleb's comment #332 (comment) this guarantee is much less important to me than it was previously. Even so, my suspicion is that it's worth still providing some pointers in the documentation.

Indeed, ToBitMask::BitMask is the type I meant to refer to. The layout of that type appears to be guaranteed by this library, in that it is u8/u16/u32/u64 rather than an opaque wrapper type around one of those integer types. It seems to me that changing those types to something wider would constitute a breaking change in the library. Likewise, changing those types when compiling for different targets would likely break portability. Am I understanding this right?

So, I think the right approach is to document ToBitMask::BitMask as "1 bit per lane, padded up to the next integer type", but I'm not confident. Going with this assumption for now, I've updated the PR to state this.

Let me know what you think.

do note that Simd<T, N> isn't guaranteed layout equivalent to [T; N] -- Simd often has greater alignment and may currently have some padding. #319 is trying to change that so Simd will never have padding (beyond what T itself has) and still may have greater alignment.

also, ToBitmask won't necessarily be implemented for all lane counts, e.g. there currently is no integer type with >128 bits so Simd<T, 129> likely won't impl ToBitmask.

if you want a bitmask type that always exists no matter the lane count, use ToBitMaskArray, though that depends on the portable-simd crate's generic_const_exprs cfg feature, which isn't currently enabled by std.

Thanks folks. I have updated wording to mention "size" rather than "layout" guarantees. I have mentioned BitMaskArray too.

(I was not familiar with the all_lane_counts crate feature. Without it, ToBitMask::BitMask is a sufficient type.)

do note that Simd<T, N> isn't guaranteed layout equivalent to [T; N] -- Simd often has greater alignment and may currently have some padding.

this means that "size guaranteed equal to [T; LANES], use Simd<T, LANES>" is currently incorrect since size_of::<Simd<T, N>>() >= size_of::<[T; N]>(), not size_of::<Simd<T, N>>() == size_of::<[T; N]>(). this is what I created #319 to fix.