[llvm] [AArch64] Define constructive EXT_ZZZI pseudo instruction (PR #152552)

[Paul Walker via llvm-commits]

================
@@ -639,10 +644,20 @@ bool AArch64ExpandPseudo::expand_DestructiveOp(
           .addImm(0);
     }
   } else if (DstReg != MI.getOperand(DOPIdx).getReg()) {
-    assert(DOPRegIsUnique && "The destructive operand should be unique");
-    PRFX = BuildMI(MBB, MBBI, MI.getDebugLoc(), TII->get(MovPrfx))
-               .addReg(DstReg, RegState::Define)
-               .addReg(MI.getOperand(DOPIdx).getReg(), DOPRegState);
+    if (DOPRegIsUnique) {
+      PRFX = BuildMI(MBB, MBBI, MI.getDebugLoc(), TII->get(MovPrfx))
+                 .addReg(DstReg, RegState::Define)
+                 .addReg(MI.getOperand(DOPIdx).getReg(), DOPRegState);
+    } else {
+      // MOVPRFX requires unique operands: Just build a COPY (Using ORR directly
+      // as we are past PostRAPseudo expansion).
+      assert(DType == AArch64::DestructiveRegRegImmUnpred &&
+             "Unexpected destructive operation type");
+      PRFX = BuildMI(MBB, MBBI, MI.getDebugLoc(), TII->get(AArch64::ORR_ZZZ))
----------------
paulwalker-arm wrote:

Well I say assumption, but it's really a logical requirement that when expanding any instruction you need to ensure the result matches the original behaviour.

The assumption is more that we only add isel for the more specific variants of DestructiveInstType when we know the expansion will be safe.  The one exception to this is the zeroing forms [1] (like the case intest_bic_zpzz_not_unique_regs) but these are guarded by `useExperimentalZeroingPseudos` because it's still a work-in-progress until we settle on the best way to solve the register allocation problem.

[1] Note there is no definition for BIC_ZPZZ_UNDEF (same goes for bfscale, the only other user DestructiveBinary), so I don't think there's anything broken that's not already guarded by an experimental flag?

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