[llvm] [AArch64] Define constructive EXT_ZZZI pseudo instruction (PR #152552)
Paul Walker via llvm-commits
llvm-commits at lists.llvm.org
Mon Aug 11 05:38:44 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))
----------------
paulwalker-arm wrote:
What if `DstReg` is not unique? I think this will corrupt the `SrcIdx` operand for the case `A = EXT_ZZZI, B, A, Imm`.
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` and thus is can be done without corrupting any of the inputs.
This is the reason we never completed the rollout to cover all instructions. Ideally we want a way to restrict the isel. I have an old patch where I tried to introduce the concept of a late read but never managed to finish it (it was quite risky).
In this instance I don't think you care about a fully general `EXT_ZZZI`? but rather just want a pseudo to represent `AArch64ext A, A, Imm` (i.e. a pseudo that takes a single register operand) that can be expanded to either `MOVPFRX B, A; EXT_ZZI B, B, Imm` or `EXT_ZZI A, A, Imm` depending on whether the destination is unique or not.
https://github.com/llvm/llvm-project/pull/152552
More information about the llvm-commits
mailing list