[AArch64][GISEL] Reduce likelihood of hash collisions for mappings in RegisterBankInfo (#87033)

Fixes #85209

This patch removes the truncation from `hash_code` aka `size_t` down to
`unsigned`, that currently happens on DenseMap accesses in
RegisterBankInfo. This reduces the likelihood of hash collisions, as
well as the likelihood of hitting EmptyKey or TombstoneKey, the special
key values of DenseMap. This is not the ultimate solution to the
problem, but we can do it in any case.

Author: marcauberer

llvm/include/llvm/CodeGen/RegisterBankInfo.h

@@ -399,22 +399,22 @@ class RegisterBankInfo {
 
   /// Keep dynamically allocated PartialMapping in a separate map.
   /// This shouldn't be needed when everything gets TableGen'ed.
-  mutable DenseMap<unsigned, std::unique_ptr<const PartialMapping>>
+  mutable DenseMap<hash_code, std::unique_ptr<const PartialMapping>>
       MapOfPartialMappings;
 
   /// Keep dynamically allocated ValueMapping in a separate map.
   /// This shouldn't be needed when everything gets TableGen'ed.
-  mutable DenseMap<unsigned, std::unique_ptr<const ValueMapping>>
+  mutable DenseMap<hash_code, std::unique_ptr<const ValueMapping>>
       MapOfValueMappings;
 
   /// Keep dynamically allocated array of ValueMapping in a separate map.
   /// This shouldn't be needed when everything gets TableGen'ed.
-  mutable DenseMap<unsigned, std::unique_ptr<ValueMapping[]>>
+  mutable DenseMap<hash_code, std::unique_ptr<ValueMapping[]>>
       MapOfOperandsMappings;
 
   /// Keep dynamically allocated InstructionMapping in a separate map.
   /// This shouldn't be needed when everything gets TableGen'ed.
-  mutable DenseMap<unsigned, std::unique_ptr<const InstructionMapping>>
+  mutable DenseMap<hash_code, std::unique_ptr<const InstructionMapping>>
       MapOfInstructionMappings;
 
   /// Getting the minimal register class of a physreg is expensive.