[llvm] [AArch64] Optimized generated assembly for bool to svbool_t conversions (PR #83001)

[Momchil Velikov via llvm-commits]

momchil-velikov wrote:

> The main concern I have about this commit is that it relies on splat_vector being always implemented using zeroing instruction. 
> Do you think it is okay to embed this reliance into the code ?

The real question is what is the canonical representation in the AArch64 backend of types like `<vscale x N x i1>` where `N < 16`.
Taking `<vscale x 8 x i1>` as an example, we know it has to represented with a bit-pattern that is `vscale * 16` bits wide. Naturally, the "active" bits are the even-numbered bits and the "inactive" bits are the odd-numbered bits.  The question is about the inactive bits. We can say they must be zero. Or we can say they can be undefined. We are going through a lot of effort to zero the "inactive" bits (that's the whole point of convert to/from svbool), which makes me think the canonical representation is with zero in "inactive" bits. Hence `splat_vector` must be lowered to instructions which yield zero in the inactive bits, other possible lowerings would be semantically incorrect.


https://github.com/llvm/llvm-project/pull/83001