[PATCH] D71396: [llvm][NFCi][lMIRVRegNamerUtils] Leverage hash_value for hashing a MachineInstr.

Puyan Lotfi via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Dec 12 12:25:35 PST 2019


plotfi updated this revision to Diff 233666.
plotfi added a comment.

Being more explicit about which MachineOperand types can be hashed and which ones can be skipped due to unstable hashing on pointers as @aditya_nandakumar mentioned. Also brought back hashing on a vreg's defining MI operand because that makes sense.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71396/new/

https://reviews.llvm.org/D71396

Files:
  llvm/lib/CodeGen/MIRVRegNamerUtils.cpp


Index: llvm/lib/CodeGen/MIRVRegNamerUtils.cpp
===================================================================
--- llvm/lib/CodeGen/MIRVRegNamerUtils.cpp
+++ llvm/lib/CodeGen/MIRVRegNamerUtils.cpp
@@ -50,23 +50,58 @@
   std::string S;
   raw_string_ostream OS(S);
 
-  // Gets a hashable artifact from a given MachineOperand (ie an unsigned).
+  // Gets a hashable artifact from a given MachineOperand (ie an unsigned). This
+  // used to be the vreg/physreg number or the immediate value, but various
+  // MachineOperand types used to be limited to just immediates, vregs/physregs,
+  // and Target Indices. This still misses a lot of artifacts like the MO type,
+  // the target flags for the MO, as well as a lot of the other operand types
+  // where we used to just return 0. Instead, it makes sense to leverage the
+  // existing MachineOperand hashing function and just has the combine range of
+  // those hashes. We should have fewer collisions then and maybe we can even
+  // eventually drop the collision handling code.
   auto GetHashableMO = [this](const MachineOperand &MO) -> unsigned {
-    if (MO.isImm())
-      return MO.getImm();
-    if (MO.isTargetIndex())
-      return MO.getOffset() | (MO.getTargetFlags() << 16);
-    if (MO.isReg() && Register::isVirtualRegister(MO.getReg()))
-      return MRI.getVRegDef(MO.getReg())->getOpcode();
-    if (MO.isReg())
-      return MO.getReg();
-    // TODO:
-    // We could explicitly handle all the types of the MachineOperand,
-    // here but we can just return a common number until we find a
+    switch (MO.getType()) {
+    case MachineOperand::MO_CImmediate:
+      return hash_combine(MO.getType(), MO.getTargetFlags(),
+                          MO.getCImm()->getZExtValue());
+    case MachineOperand::MO_FPImmediate:
+      return hash_combine(
+          MO.getType(), MO.getTargetFlags(),
+          MO.getFPImm()->getValueAPF().bitcastToAPInt().getZExtValue());
+    case MachineOperand::MO_Register:
+      // In the case of a vreg, it's better to hash on the opcode since that
+      // has more semantic meaning that whatever the vreg number is. For
+      // physregs we do want to hash on the register itself.
+      if (Register::isVirtualRegister(MO.getReg()))
+        return MRI.getVRegDef(MO.getReg())->getOpcode();
+      LLVM_FALLTHROUGH;
+    case MachineOperand::MO_Immediate:
+    case MachineOperand::MO_FrameIndex:
+    case MachineOperand::MO_ConstantPoolIndex:
+    case MachineOperand::MO_TargetIndex:
+    case MachineOperand::MO_JumpTableIndex:
+    case MachineOperand::MO_CFIIndex:
+    case MachineOperand::MO_IntrinsicID:
+    case MachineOperand::MO_Predicate:
+      return llvm::hash_value(MO);
+    // We explicitly handle all types of MachineOperands that will result in a
+    // stable hash. In the cases below we havn't found a way to that. Instead
+    // we 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.
-    return 0;
+    case MachineOperand::MO_MachineBasicBlock:
+    case MachineOperand::MO_ExternalSymbol:
+    case MachineOperand::MO_GlobalAddress:
+    case MachineOperand::MO_BlockAddress:
+    case MachineOperand::MO_RegisterMask:
+    case MachineOperand::MO_RegisterLiveOut:
+    case MachineOperand::MO_Metadata:
+    case MachineOperand::MO_MCSymbol:
+    case MachineOperand::MO_ShuffleMask:
+      return 0;
+    }
+    llvm_unreachable("Unexpected MachineOperandType.");
   };
 
   SmallVector<unsigned, 16> MIOperands = {MI.getOpcode(), MI.getFlags()};


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D71396.233666.patch
Type: text/x-patch
Size: 3713 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20191212/2fbc7bd9/attachment.bin>


More information about the llvm-commits mailing list