Add integer bitmask

[b8591340]

Maybe rename to_bitmask to to_bitmask_array and restore to_bitmask to return IntBitMask as in packed_simd, or viceversa.

[calebzulawski]

To get the bytes as an integer, you can use u32::from_ne_bytes, etc.

[b8591340]

As far as I can see that wouldn’t work with generic const exprs—the API should return IntBitMask so that we can do <const N: usize> where LaneCount<N>: SupportedLaneCount, [(); LaneCount::<N>::BITMASK_LEN]: without having to transmute or hook into LLVM’s simd_bitmask ourselves.

[calebzulawski]

IntBitMask is a workaround for the current limitations in the simd_bitmask intrinsic. In the future, that type will be gone, which will allow bitmasks of masks of any size. Future versions of std::simd may support vectors with more lanes than bits in any integer type.

In the case of generics, you could do something like:

fn bitmask_to_u64<const BYTES: usize>(bitmask: [u8; BYTES]) -> u64 {
    assert!(BYTES <= 8);
    let mut padded = [0; 8];
    padded[..BYTES].copy_from_slice(&bitmask[..BYTES]);
    u64::from_ne_bytes(padded)
}

[b8591340]

I see. Thanks for the comment and the suggestion. I would want to abstract over the integer types in function of the associated type of the given supported lane, but I see it was misguided as there’s no std way to abstract over integers—i.e. if I want to ctlz the bitmask I cannot do that generically.

I am using macros as it is, but if we could const abstract over integer primitives (e.g. u<8>) and have them be arbitrary-sized (like Zig) it would work with arbitrary-sized masks up to the LLVM threshold.

Not sure how complex or desirable it’d be, and if this is the right place to kickstart a discussion, but it could be considered in light of this effort.

[calebzulawski]

Generic integers came up a few times when we were designing this interface--if they were available I think it would be the preferable route. I'm not sure how complex it would be either, but it's come up enough times that there's definitely some desire for it. We more or less settled on u8 arrays being "good enough", but not perfect.

[workingjubilee]

Resolved in #239.