[AArch64][NFC] Change order of instructions in isAssociativeAndCommutative

[kawashima-fj]

Summary

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 after this patch is accepted.

[dmgreen]

Sounds good to me. LGTM.

llvm/lib/Target/AArch64/AArch64InstrInfo.cpp

 //       1. Other data types (integer, vectors)
 //       2. Other math / logic operations (xor, or)
 //       3. Other forms of the same operation (intrinsics and other variants)
 bool AArch64InstrInfo::isAssociativeAndCommutative(const MachineInstr &Inst,
                                                    bool Invert) const {
   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;
   }
 }
 
 /// Find instructions that can be turned into madd.
 static bool getMaddPatterns(MachineInstr &Root,
                             SmallVectorImpl<MachineCombinerPattern> &Patterns) {