Tweak SIMDWrapper conversions / operations
Various small changes to ensure that SIMDWrapper types behave predictably, particularly in generic code:
- Specialise
std::numeric_limits<T>
forSIMDWrapper
types, patching up the previous behaviour wherestd::numeric_limits<[some SIMDWrapper type>
would despatch to the default implementation, returning default-constructed objects that were uninitialised values...- In generic code that uses
std::numeric_limits
we should strongly encourage the use ofstatic_assert( std::numeric_limits<T>::is_specialized )
... - Unfortunately the specialisations are not quite conformant, because they are not
constexpr
and some methods are missing...this is difficult to fix given that the underlying intrinsic functions are notconstexpr
- In generic code that uses
- Add compile-time tests that
std::common_type_t
operating on combinations ofSIMDWrapper
types yields the expected (i.e. matching plain C++ types) results.- These did not pass; make some conversions
explicit
so that they do (nowfloat_v
->int_v
is explicit,int_v
->float_v
andmask_v
->int_v
are not) - Remove implicit
scalar::mask_v
->int
conversion and addbool cast() const
- These did not pass; make some conversions
- Ensure that
mask_v{} + mask_v{}
consistently yieldsint_v
, asbool{} + bool{}
does- This is incompatible with the old approach of
avx2::mask_v
being an alias foravx2::float_v
, so define an explicitmask_v
(which also makes the API more consistent across backends...) - Also try to ensure that
int_v{mask_true()} == int_v{1}
andint_v{mask_false()} == int_v{0}
- This is incompatible with the old approach of
- Improve some output operators.
- Tidy up function signatures to more consistently use
int_v/float_v/mask_v
types instead of relying on implicit conversions. - Add a converting constructor for
Vec3<U>
->Vec3<T>
- Add a deduction guide for
Vec3{T1, T2, T3}
->Vec3<std::common_type_t<T1, T2, T3>>
- Make the
gather_XXX
signature forVec3
consistent by removing a template argument and instead deducing the return type from the index vector type.
There was some mild fallout in other code that relied on implicit conversions that are no longer implicit; depends on Rec!2109 (merged).
Edited by Olli Lupton