Some things to consider:
- NEON currently lowers the 64-bit and 128-bit vector AND reductions to a tree based algorithm, IINM. Do we want to go with the NEON lowerings or SVE instructions for those? The i8 and i16 cases should probably use SVE for code clarity. But the v2 vectors may be short enough that NEON is a win. They'll expand to something like:
ext v1.16b, v0.16b, v0.16b, #8 and v0.8b, v0.8b, v1.8b
Are we okay with tuning these later? Or should I do a study now?
- If we choose SVE instructions for #1, the OverrideNEON flag is getting bulky again. We might want to consider refactoring that, since we'll need to add more cases for OR and XOR.
- I named the new test file sve-fixed-length-log-reduce.ll. The log follows the existing AND tests in /AArch64, but is a little misleading since they're bitwise operations, not logical. Any suggestions on alternative names?
Can you add VBITS_EQ_256 check lines to the VBITS_GE_512 related tests to ensure sensible type legalisation. See sve-fixed-length-int-minmax.ll for example. It looks like I missed this for the other reduction tests.