[NFC][llvm][MIRVRegNamerUtils] Moving some switch cases and altering …

…comments.
YuriPlyakhin · Dec 16, 2019 · 204dfab · 204dfab
1 parent 549545b
commit 204dfab
Showing 1 changed file with 5 additions and 5 deletions.
diff --git a/llvm/lib/CodeGen/MIRVRegNamerUtils.cpp b/llvm/lib/CodeGen/MIRVRegNamerUtils.cpp
@@ -60,22 +60,22 @@ std::string VRegRenamer::getInstructionOpcodeHash(MachineInstr &MI) {
       return hash_combine(
           MO.getType(), MO.getTargetFlags(),
           MO.getFPImm()->getValueAPF().bitcastToAPInt().getZExtValue());
-    case MachineOperand::MO_Immediate:
-      return MO.getImm();
-    case MachineOperand::MO_TargetIndex:
-      return MO.getOffset() | (MO.getTargetFlags() << 16);
     case MachineOperand::MO_Register:
       if (Register::isVirtualRegister(MO.getReg()))
         return MRI.getVRegDef(MO.getReg())->getOpcode();
       return MO.getReg();
+    case MachineOperand::MO_Immediate:
+      return MO.getImm();
+    case MachineOperand::MO_TargetIndex:
+      return MO.getOffset() | (MO.getTargetFlags() << 16);
 
     // We could explicitly handle all the types of the MachineOperand,
     // here but we can just return a common number until we find a
     // compelling test case where this is bad. The only side effect here
     // is contributing to a hash collision but there's enough information
     // (Opcodes,other registers etc) that this will likely not be a problem.
 
-    // TODO: Handle the following Immediate/Index/ID/Predicate cases. They can
+    // TODO: Handle the following Index/ID/Predicate cases. They can
     // be hashed on in a stable manner.
     case MachineOperand::MO_FrameIndex:
     case MachineOperand::MO_ConstantPoolIndex: