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

Gaƫtan Bossu via llvm-commits llvm-commits at lists.llvm.org
Mon Aug 11 06:39:49 PDT 2025


================
@@ -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))
----------------
gbossu wrote:

See https://github.com/llvm/llvm-project/pull/152552#discussion_r2266789374, you are correct that one of the inputs will be overwritten. I do like your suggestion of a pseudo to support `AArch64ext A, A, Imm` only, because it is the pattern I care about, and it is then easy to safely lower the pseudo.

Howerver, note that this assumption is wrong (at least that's my understanding):
> There's an assumption with the pseudo expansion that if DstReg must be written to, then they'll always be a way to do this with MOVPFRX

I think this does not work for `DestructiveBinary` pseudos, and this is reflected in the `test_bic_zpzz_not_unique_regs` test case.

Do you know if that assumption is documented somewhere? If it's not documented, I'll probably mention it where `DestructiveInstTypeEnum` is defined.

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


More information about the llvm-commits mailing list