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

[via llvm-commits]

Lukacma 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.
> 
> By design the "invisible bits" within a predicate type are undefined. When changing the visibility of bits via the to/from_svbool intrinsics we didn't want to leave newly visible bits hanging and so to_svbool defines them as zero. ` isZeroingInactiveLanes` exists to reduce the need to explicitly zero these lanes by entering certain operations into a contract to guarantee all isel related to them will zero their invisible lanes.
> 
> I suspect the reason that non-constant `SPLAT_VECTOR`'s were omitted is because they don't typically come from ACLE code where to_svbool is prevalent. Out of interest, in what context are you seeing them today?

In the test I have an example, where previously splat_vectors were used to go from scalar to vector type : 
```
#define <vscale x 16 x i1> @reinterpret_scalar_bool_h(i1 %x){
; CHECK-LABEL: reinterpret_scalar_bool_h:
; CHECK:       // %bb.0:
; CHECK-NEXT:    // kill: def $w0 killed $w0 def $x0
; CHECK-NEXT:    sbfx x8, x0, #0, #1
; CHECK-NEXT:    whilelo p0.h, xzr, x8
; CHECK-NEXT:    ret
  %.splatinsert = insertelement <vscale x 8 x i1> poison, i1 %x, i64 0
  %.splat = shufflevector <vscale x 8 x i1> %.splatinsert, <vscale x 8 x i1> poison, <vscale x 8 x i32> zeroinitializer
  %out = tail call <vscale x 16 x i1> @llvm.aarch64.sve.convert.to.svbool.nxv8i1(<vscale x 8 x i1> %.splat)
  ret <vscale x 16 x i1> %out
}
```

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