[llvm][MIRVRegNamer] Avoid collisions across jump table indices.

[plotfi]

Summary

Hash Jump Table Indices uniquely within a basic block.

[aditya_nandakumar]

I'm beginning to wonder if maybe it makes sense to put all of these individual tests, in one place instead of being scattered across many tests (considering they're all testing the same thing) so it's easier to find.
Not related to this, but this patch LTGM.

[plotfi]

In D77966#1977156, @aditya_nandakumar wrote:

I'm beginning to wonder if maybe it makes sense to put all of these individual tests, in one place instead of being scattered across many tests (considering they're all testing the same thing) so it's easier to find.
Not related to this, but this patch LTGM.

Sounds good. I can prob post a follow up NFC consolidating some mir-canon tests.

llvm/lib/CodeGen/MIRVRegNamerUtils.cpp

case MachineOperand::MO_Register:
         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);
     case MachineOperand::MO_FrameIndex:
     case MachineOperand::MO_ConstantPoolIndex:
+    case MachineOperand::MO_JumpTableIndex:
       return llvm::hash_value(MO);
 
     // 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 Index/ID/Predicate cases. They can
     // be hashed on in a stable manner.
-    case MachineOperand::MO_JumpTableIndex:
     case MachineOperand::MO_CFIIndex:
     case MachineOperand::MO_IntrinsicID:
     case MachineOperand::MO_Predicate:
 
     // In the cases below we havn't found a way to produce an artifact that will
     // result in a stable hash, in most cases because they are pointers. We want
     // stable hashes because we want the hash to be the same run to run.
     case MachineOperand::MO_MachineBasicBlock:

llvm/test/CodeGen/MIR/AArch64/mir-canon-jump-table.mir

+# RUN: llc -run-pass mir-canonicalizer -verify-machineinstrs -mtriple aarch64-unknown-linux-gnu -o - %s | FileCheck %s
+...
+---
+name: foo
+alignment:       16
+jumpTable:
+  kind:  block-address
+  entries:
+    - id:              0
+      blocks:          [ '%bb.0', '%bb.1']
+    - id:              1
+      blocks:          [ '%bb.2', '%bb.3' ]
+    - id:              2
+      blocks:          [ '%bb.3', '%bb.7']
+    - id:              3
+      blocks:          [ '%bb.2', '%bb.3' ]
+body:             |
+  bb.0:
+  bb.1:
+  bb.2:
+  bb.3:
+  bb.7:
+    ;CHECK: %bb{{[0-9]+}}_{{[0-9]+}}__1:_(p0) = G_JUMP_TABLE %jump-table.0
+    ;CHECK: %bb{{[0-9]+}}_{{[0-9]+}}__1:_(p0) = G_JUMP_TABLE %jump-table.1
+    ;CHECK: %bb{{[0-9]+}}_{{[0-9]+}}__1:_(p0) = G_JUMP_TABLE %jump-table.2
+    ;CHECK: %bb{{[0-9]+}}_{{[0-9]+}}__1:_(p0) = G_JUMP_TABLE %jump-table.3
+    %a:_(p0) = G_JUMP_TABLE %jump-table.0
+    %b:_(p0) = G_JUMP_TABLE %jump-table.1
+    %c:_(p0) = G_JUMP_TABLE %jump-table.2
+    %d:_(p0) = G_JUMP_TABLE %jump-table.3
+
+...
+