Unify scalar, batch, and batch_bool in some places

[kalenedrael]

• Add batch_traits that unifies traits for scalar, batch, and batch_bool.
• Treat batch_bool as its own mask type.
• Add casts for scalar types.
• Add select() for batch_bool.
• Simplify abs implementation.

[kalenedrael]

FWIW, the goal is to make it easier to write generic code that works on scalar and batch types. For instance, this enables something like:

template <typename VecF, VecI, VecB>
VecF DoStuff(VecF fv, VecI iv, VecB cond) {
  using F = typename batch_traits<VecF>::scalar_type;
  auto cond_i = iv > 42;
  return select(batch_cast<F>(cond_i) & cond, fv + batch_cast<F>(iv), 0.0));
}

which can be used as DoStuff(float, int, bool) or DoStuff(batch<float>, batch<int>, batch_bool<float>).

Unifying batch_bool with batch enables code like this to work for either type (at least it would, if select supported batch_bool, which I will add):

template <typename Vec>
auto LoadSelect(bool *b, Vec x, Vec y) {
  using VecB = typename batch_traits<Vec>::mask_type;
  return select(VecB::load_unaligned(b), x, y);
}

Tangentially related: I wonder if, in general, batch_bool should be parameterized on vector size instead of the underlying type. It's a bit strange to say that a boolean can only be used on a particular scalar type. Unfortunately, at least on x86, there is a distinction between integer and floating point vector types, and on many older processors there is a performance penalty for crossing domains. This can basically be ignored on any newer processor, but it's something to keep in mind.

[serge-sans-paille]

• Add batch_traits that unifies traits for scalar, batch, and batch_bool.

I like that!

* `batch_cast` can now be used on `batch_bool` (because why not?)

I 'm not quite sure about this one. We currently have a conversion operator from batch_bool to batch and within that setup I find it confusing to have a batch_cast on a a batch_bool returning a batch_bool.

[kalenedrael]

True. Do you think it's better to allow implicit conversion between batch_bool of the same size?

[serge-sans-paille]

True. Do you think it's better to allow implicit conversion between batch_bool of the same size?

I'm not a big fan of this either :-/
Just because explicit is better than implicit.

[kalenedrael]

I'll remove it from this PR; I think the other features are enough for what I want at the moment.

The problem I'm trying to solve is that batch_bool_cast is fundamentally nonsensical. There's no conceptual reason the result of an integer comparison shouldn't be directly usable for conditioning float expressions, for instance. Unfortunately I don't have a good solution yet.

[kalenedrael]

Ok, select for batch_bool has been added. This is ready now; please let me know if you have any concerns.

[serge-sans-paille]

This seems sub-optimal in the case where we don't have access to a fast select, see https://godbolt.org/z/3GqaxTsbd

[kalenedrael]

There's no earthly reason GCC should generate different code for the two implementations. Maybe it's hung up on generating andn and refuses to const-prop through it, so it has to copy the mask as well as the inputs. Clang does just fine: https://godbolt.org/z/6766ExWMK

I tested both versions in a loop as well (https://godbolt.org/z/Gxe4E4fK5). GCC uses and and andn with one mask with the current implementation but two masks for your version. It's a tradeoff of one movaps r, r vs using another (architectural) register; which version is better probably depends on the context. I'm happy to change it if you can explain why one option is clearly better than the other, but this feels like a rather brittle optimization.

[serge-sans-paille]

you're correct, it's very compiler dependent, and probably also context dependent. Let's keep the code simple, and change later if it creates an issue for someone else.

[kalenedrael]

I'll use your version as it seems simpler for now, rather than dispatching to the batch<T> version.

[serge-sans-paille]

Would you mind rewriting history to have (at least) one commit for abs, one for the various cast, one for select?
Otherwise LGTM

[kalenedrael]

Sure thing, that's a good idea.

[serge-sans-paille]

thanks! 🙇