Change representation of instruction set extensions

[serge-sans-paille]

Both Intel and ARM have instruction set extensions : fma for intel, i8mm for arm, not counting the avx512 extensions too.
We currently represent these extensions as a parametric type parametrized by the instruction set it extends, eg fma<avx>.

It would be nice to explore a more intuitive representation, maybe avx<fma, ...> ?

[serge-sans-paille]

extra thoughts: this would make it possible to catch avx2 extensions brought by avx512, and that's quite nice!

[serge-sans-paille]

@DiamonDinoia / @AntoinePrv / @JohanMabille : I'll use this bug to track my progress and thoughts on that topic: I'm currently experimenting with defining a instruction set named avx2_128 that inherits from avx_128 that inherits from sse4_2. It turns out it's pretty straight-forward, if you want to use those batches you just use the appropriate architecture name, which can be read as "avx extension for 128 bits registers".
I plan to submit the avx extensions to 128 bit registers this week, so that we have something to churn.

[DiamonDinoia]

Sounds like a good idea!

We could use markdown checklists ( - [ ] ) to plan ahead if that is not too much of a hassle. Maybe to have a general overview.

[DiamonDinoia]

Just dropping some name suggestions in case: avx2_xmm and avx2_w128.

[DiamonDinoia]

@serge-sans-paille I see two options here:

1. the FMA way where we use CTAD
2. the inheritance way with avx_128 -> SSE4.2 and so on.

Do you think number 2 is best here? What is the tradeoff?

[AntoinePrv]

last I look at the intrinsicts, 128 bits operations in avx were really a patch to the missing operations in the sse family (say one operation was done for integers of size 1, 2, 4, but not 8).
Given it uses the same xmm registers as sse, I think 2. is the cleanest option.

[serge-sans-paille]

See #1329 for avx_128 support. Any comments are welcome!

I tend to agree with @AntoinePrv on the general approach, esp. after this initial try for avx. So we need to do:

• avx_128
• avx2_128
• avx512f_128
• avx512f_256

and so one for all avx512 sub-architectures.

We could also do

• neon_64
• neon64_64 // < what a bad naming

but I'm unsure we want to go that way, do we?

[AntoinePrv]

Naming wise, we could consider doing avx<std::size_t width = 256>, with explicit specialization.

The advantage is that it mirrors (for different reasons) what is done for SVE and RVV, and give users a programmatic way to change their register sizes across a variety of implementations.
In practice this may be a bit more annoying to implement.

Not sure about Neon, I see multiple reasons not to include:

• xsimd is about generic code and this is the only 64 SIMD size
• With AVX there are good reasons for wanting to reduce the size:
  • In practice 256 and 512 can sometime be too large for some algortihms while 128 is generally OK
  • 256 and above (YMM, ZMM registers) can separately be disabled at the OS level for various reasons (Context switching state cost, power management...). In these cases it's good to still be able to leverage advanced instructions without relying on algorithmic fallbacks.