[PATCH] D139607: [AArch64][NFC] Change order of instructions in isAssociativeAndCommutative

[KAWASHIMA Takahiro via Phabricator via llvm-commits]

kawashima-fj created this revision.
kawashima-fj added a reviewer: dmgreen.
kawashima-fj added a project: LLVM.
Herald added subscribers: hiraditya, kristof.beyls.
Herald added a project: All.
kawashima-fj requested review of this revision.
Herald added a subscriber: llvm-commits.

Before this change, the order of instructions in `case` labels is inconsistent. It is alphabetical order for FP instructions but another order for integer instructions. This commit changes the order to 1) instruction set (base/FP/SIMD), 2) mnemonic, 3) element type. I believe this change makes it consistent, improves understandability, and makes it easy to add/remove a group of instructions.

I'll submit some patches to add instructions to the function which replaces D138107 <https://reviews.llvm.org/D138107> after this patch is accepted.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D139607

Files:
  llvm/lib/Target/AArch64/AArch64InstrInfo.cpp


Index: llvm/lib/Target/AArch64/AArch64InstrInfo.cpp
===================================================================
--- llvm/lib/Target/AArch64/AArch64InstrInfo.cpp
+++ llvm/lib/Target/AArch64/AArch64InstrInfo.cpp
@@ -4944,35 +4944,47 @@
   if (Invert)
     return false;
   switch (Inst.getOpcode()) {
-  case AArch64::FADDDrr:
+  // == Floating-point types ==
+  // -- Floating-point instructions --
   case AArch64::FADDSrr:
-  case AArch64::FADDv2f32:
-  case AArch64::FADDv2f64:
-  case AArch64::FADDv4f32:
-  case AArch64::FMULDrr:
+  case AArch64::FADDDrr:
   case AArch64::FMULSrr:
+  case AArch64::FMULDrr:
   case AArch64::FMULX32:
   case AArch64::FMULX64:
-  case AArch64::FMULXv2f32:
-  case AArch64::FMULXv2f64:
-  case AArch64::FMULXv4f32:
+  // -- Advanced SIMD instructions --
+  case AArch64::FADDv2f32:
+  case AArch64::FADDv4f32:
+  case AArch64::FADDv2f64:
   case AArch64::FMULv2f32:
-  case AArch64::FMULv2f64:
   case AArch64::FMULv4f32:
+  case AArch64::FMULv2f64:
+  case AArch64::FMULXv2f32:
+  case AArch64::FMULXv4f32:
+  case AArch64::FMULXv2f64:
     return Inst.getParent()->getParent()->getTarget().Options.UnsafeFPMath ||
            (Inst.getFlag(MachineInstr::MIFlag::FmReassoc) &&
             Inst.getFlag(MachineInstr::MIFlag::FmNsz));
-  case AArch64::ADDXrr:
-  case AArch64::ANDXrr:
-  case AArch64::ORRXrr:
-  case AArch64::EORXrr:
-  case AArch64::EONXrr:
+
+  // == Integer types ==
+  // -- Base instructions --
+  // Opcodes MULWrr and MULXrr don't exist because
+  // `MUL <Wd>, <Wn>, <Wm>` and `MUL <Xd>, <Xn>, <Xm>` are aliases of
+  // `MADD <Wd>, <Wn>, <Wm>, WZR` and `MADD <Xd>, <Xn>, <Xm>, XZR` respectively.
+  // The machine-combiner does not support three-source-operands machine
+  // instruction. So we cannot reassociate MULs.
   case AArch64::ADDWrr:
+  case AArch64::ADDXrr:
   case AArch64::ANDWrr:
+  case AArch64::ANDXrr:
   case AArch64::ORRWrr:
+  case AArch64::ORRXrr:
   case AArch64::EORWrr:
+  case AArch64::EORXrr:
   case AArch64::EONWrr:
+  case AArch64::EONXrr:
     return true;
+
   default:
     return false;
   }


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D139607.481165.patch
Type: text/x-patch
Size: 2097 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20221208/792f7301/attachment.bin>