[llvm] [AArch64][SVE] Handle some cases of uzp1/reinterpret from svbool in isZeroingInactiveLanes (PR #78623)

[Paul Walker via llvm-commits]

================
@@ -283,6 +283,24 @@ static bool isZeroingInactiveLanes(SDValue Op) {
     switch (Op.getConstantOperandVal(0)) {
     default:
       return false;
+
+    case Intrinsic::aarch64_sve_uzp1:
+      return isZeroingInactiveLanes(Op.getOperand(1)) &&
+             isZeroingInactiveLanes(Op.getOperand(2));
----------------
paulwalker-arm wrote:

I'm not so sure this is the correct place for such code because the function related to zeroing through construction rather than propagation. It is a bit of a kludge but I find comfort in knowing it only handles a specific set of intrinsics that we know have no special handling.  Once you start recursing down the DAG I start to feel less comfortable.

That said, `aarch64_sve_uzp1` is also a weird intrinsic because for predicates only the `nxv16i1` case is tied by design to a specific instruction (i.e. it's not one of the intrinsics where, at least as of today, we've attached any meaning to the invisible lanes).  I only maintained the support for other predicate types when creating https://reviews.llvm.org/D142065 because it seemed useful to maintain it as a way to logically interleave two vectors.  But we have dedicated target neutral intrinsics for that now.

So I guess my question is in what circumstance do you need to support `to_svbool(sve.uzp1(val))`? I wasn't expecting to see this from ACLE code for example.  I'm not against the patch but I would like to understand the rational more.

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