Add optional num-traits bounds on SimdBase::Element

[danderson]

While writing helpers that are generic over the simd type, one painful part is that (afaict) there's no way to create SimdBase::Element values, because the associated type has no bounds. This means for example you can't do a T::splat of a calculated value, instead the caller has to pass values in from a context where the type is concrete.

Perhaps: add the following bounds to SimdBase::Element: From<u8> + TryFrom<u16> + TryFrom<u32> + TryFrom<u64> + TryFrom<f32> + TryFrom<f64>.

u8 is the only conversion that's guaranteed to succeed for all simd types, the others might fail on certain combinations (e.g. converting u64 to a u8x64::Element), so they have to be TryFrom. Given that simd functions have to be aggressively inlined, I think it's likely that the failure branch will be elided in most real code.

Going further, maybe define a custom conversion trait that allows all three main conversion flavors (checked, saturating, wrapping)?

pub trait FromScalar<T> {
    type Err;

    fn checked_from(v: T) -> Result<Self, Self::Err>;

    fn saturating_from(v: T) -> Self;

    fn wrapping_from(v: T) -> Self;
}

For my own code the values will never overflow so wrapping/truncating conversion would be the most efficient, I don't know if other code would benefit from the other conversion styles.

[Shnatsel]

Could you share an example of where this comes up so I could see it in context?

[danderson]

Not a fully worked out example, but https://gist.github.com/danderson/d923b58fea2755679aff91cad8706411 is a simple case of bit unpacking without carry. Logically, the mask and iteration count derive trivially from the shift amount provided by the caller (which must be a u32 since that's the Shr impl that exists).

Without a way to create T::Element though, I have to write the second form, where the caller must pass in both shift and mask values, and has to ensure that they are consistent with each other.

This gets worse in the unpack-with-carry case, because to handle the boundary condition between two words the function needs 3 different masks. They can all be computed from the shift amounts and T::Element::BITS, but with no way to convert to T::Element the caller has to create and pass in all 3 masks. There are other clunky options, like passing in an all-ones T so that the helper can create the masks it needs by shifting, but that makes it less obvious to the compiler that, in many cases, the masks are actually compile-time constants that can be optimized into trivial splats.

[Shnatsel]

If we add https://docs.rs/num-traits/latest/num_traits/ bounds on T::Element, int and float respectively depending on the vector type, will that be sufficient? I feel like we're just going to reinvent that piecemeal over the course of a year if we add our own bounds, so might as well just adopt the ecosystem solution right away for better interop. Or is that overkill?

[danderson]

Hmm, I think that works too and it would be nice to also have other operations available. One thing I'm seeing is that the traits for float are less rich than int. Element is defined on SimdBase so it can only support lowest common denominator across float and int. Either that or get rid of SimdBase and just have separate but similar SimdInt and SimdFloat with slightly different bounds, but that's a lot of churn.

[danderson]

Oh never mind I misread and didn't see that Float inherits Num. So probably Num and maybe a few extras would be fine, I'd have to read the trait stack in detail to see if there needs to be more than just Num. I can do that a bit later today and send a PR if you like.

[Shnatsel]

It needs to be an opt-in Cargo feature but yeah I'd be happy to see a PR for that.

I've just realized that now that SimdBase no longer includes masks we could put equivalents of Num and NumOps on it as well, like Add and such.