Feature/simplify masks

[calebzulawski]

Remove explicit bitmasks.

Add ToBitMask trait which allows you to convert masks to u64.

[programmerjake]

what happens in the future when we get 256-element vectors? are masks just not supported?!

[calebzulawski]

I'm not sure. I'm still thinking about that. Unfortunately there's basically no way to represent that in the rust type system as far as generics go. Related to #50

[programmerjake]

I'm not sure. I'm still thinking about that. Unfortunately there's basically no way to represent that in the rust type system as far as generics go. Related to #50

An idea for fixing that:
#50 (comment)

[workingjubilee]

@programmerjake We will absolutely successfully work out a version that does not break on 2048-bit vectors with byte lanes before we stabilize anything (or else over my dead body, I suppose). You can expect to see this API change a lot, please do not read too much into any single version. Right now, we're trying things out a lot and seeing how things work.

"How to handle masks on platforms" is definitely going to be an Unresolved Question in our RFC.

[calebzulawski]

I think there are two separate things here that we need to consider.

One is that masks of any (reasonable) vector length should be supported, regardless of their implementation. That could be solved by using a trait like that (it may be appropriate as part of LanesAtMost32 or whatever we end up calling it).

But I think there is a separate problem of explicitly exposing a mask as an integer bitmask. This is the SSE movemask example, where you use your bitmask as an index to a lookup table or similar. It's possible to have a 256-lane vector, but I don't think it's useful to expose an entire 256-bit "integer". Or, hypothetically, if we support Mask8<65536> in the future, I don't think there's any (portable!) way of exposing that. On AVX-512 is that 2048 k registers placed into an array in memory? I can't think of many (portable!) reasons you'd need to access that as a [u8]. This is what the ToBitMask trait is for, converting masks with up to 64 lanes into u64s, independently of the maximum supported number of mask lanes.

[calebzulawski]

Anyone know why the MIPS masks seem to be reversed when packed to an integer? Somehow an LLVM bug or is there something peculiar about MIPS?

[programmerjake]

IDK, but maybe it's related to Ada bit array ordering?

[workingjubilee]

...Ada bit array?

[programmerjake]

...Ada bit array?

They describe it some here:
https://en.wikibooks.org/wiki/Ada_Programming/Types/array#With_aliased_elements

[calebzulawski]

I think that leaves me with more questions than I started with. What do Ada arrays have to do with this?

[programmerjake]

Well, when discussing which order to have bitmasks in SimpleV, lxo (one of the GCC Ada compiler engineers who's helping out with Libre-SOC) mentioned that Ada uses MSB to LSB ordering for bit arrays -- I figured that might be related since it uses the same order as what you apparently noticed in MIPS.

[calebzulawski]

Hmm. I'd hope that's not related to the problem. I would expect LLVM to maintain consistent bit field ordering across architectures.

[workingjubilee]

Can you rebase this, please?

[calebzulawski]

Okay. "Simplify" might be a bit of a misnomer now (but the API is definitely simplified!)

I used a Mask helper trait to mostly fix #50. I didn't use const_evaluatable_unchecked to implement the trait over all masks, but it should be possible in the future, effectively solving that problem.

Bit masks are now implemented as arrays of u8 and can be exposed to the users of stdsimd that way, too. If you want an integer you'll have to do the conversion yourself (not that big of a deal). Due to limitations in the simd_bitmask and simd_select_bitmask intrinsic, Mask has an extra IntBitMask associated type, which is purely used internally. We should be able to remove that after improving the intrinsics to accept arrays of u8 as bitmasks as well.

[workingjubilee]

This wound up not simplifying things as much as intended internally but it looks much better to me as an external API, really, which is what counts here. Can you add "modify Rust SIMD intrinsics to accept u8-or-something bitmasks" to #46 with a note about all the ones that need to get touched?