[PATCH] Switch a std::map to a DenseMap in CodeGenRegisters

[Duncan P. N. Exon Smith]

> On 2015-Feb-10, at 14:02, Owen Anderson <resistor at mac.com> wrote:
> 
> Hi chandlerc, joker.eph,
> 
> As far as I can tell, the keys of the map are unique by pointer address, so there's no need to use the llvm::less comparator.

This change also makes iteration order non-deterministic.

This map type is iterated through during
`CodeGenRegister::computeSubRegs(CodeGenRegBank &)`:

    SmallVector<CodeGenSubRegIndex*, 8> Indices = ExplicitSubRegIndices;
    for (unsigned i = 0; i != Indices.size(); ++i) {
      CodeGenSubRegIndex *Idx = Indices[i];
      const CodeGenSubRegIndex::CompMap &Comps = Idx->getComposites();
      CodeGenRegister *SR = SubRegs[Idx];
      const SubRegMap &Map = SR->computeSubRegs(RegBank);

      // Look at the possible compositions of Idx.
      // They may not all be supported by SR.
      for (CodeGenSubRegIndex::CompMap::const_iterator I = Comps.begin(),
             E = Comps.end(); I != E; ++I) {
        SubRegMap::const_iterator SRI = Map.find(I->first);
        if (SRI == Map.end())
          continue; // Idx + I->first doesn't exist in SR.
        // Add I->second as a name for the subreg SRI->second, assuming it is
        // orphaned, and the name isn't already used for something else.
        if (SubRegs.count(I->second) || !Orphans.erase(SRI->second))
          continue;
        // We found a new name for the orphaned sub-register.
        SubRegs.insert(std::make_pair(I->second, SRI->second));
        Indices.push_back(I->second);
      }
    }

By inspection, it looks like the iteration order could eventually
affect the contents of `SubRegs`, depending on whether there could
be duplicates of `I->second` in `Comps`.  But I don't actually know
this code... maybe `I->second` is guaranteed to be unique?

Also, in `RegisterInfoEmitter.cpp`:

    static bool combine(const CodeGenSubRegIndex *Idx,
                        SmallVectorImpl<CodeGenSubRegIndex*> &Vec) {
      const CodeGenSubRegIndex::CompMap &Map = Idx->getComposites();
      for (CodeGenSubRegIndex::CompMap::const_iterator
           I = Map.begin(), E = Map.end(); I != E; ++I) {
        CodeGenSubRegIndex *&Entry = Vec[I->first->EnumValue - 1];
        if (Entry && Entry != I->second)
          return false;
      }
    
      // All entries are compatible. Make it so.
      for (CodeGenSubRegIndex::CompMap::const_iterator
           I = Map.begin(), E = Map.end(); I != E; ++I)
        Vec[I->first->EnumValue - 1] = I->second;
      return true;
    }

The results of the first loop are obviously independent of iteration
order.  I'm not sure of the second... if `Map` has two entries with
the same `EnumValue` (but different `I->second`) the result would be
non-deterministic.

> This allows us to use DenseMap instead, which reduces tblgen time by 20% on my stress test.
> 
> REPOSITORY
>  rL LLVM
> 
> http://reviews.llvm.org/D7544
> 
> Files:
>  utils/TableGen/CodeGenRegisters.h
> 
> Index: utils/TableGen/CodeGenRegisters.h
> ===================================================================
> --- utils/TableGen/CodeGenRegisters.h
> +++ utils/TableGen/CodeGenRegisters.h
> @@ -74,8 +74,7 @@
>     std::string getQualifiedName() const;
> 
>     // Map of composite subreg indices.
> -    typedef std::map<CodeGenSubRegIndex *, CodeGenSubRegIndex *,
> -                     deref<llvm::less>> CompMap;
> +    typedef DenseMap<CodeGenSubRegIndex *, CodeGenSubRegIndex *> CompMap;
> 
>     // Returns the subreg index that results from composing this with Idx.
>     // Returns NULL if this and Idx don't compose.
> 
> EMAIL PREFERENCES
>  http://reviews.llvm.org/settings/panel/emailpreferences/
> <D7544.19709.patch>_______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits