Switch the new COFF linker's symbol table to use a DenseMap of

StringRefs. This uses the LLVM hashing rather than the standard library
and a closed addressed hash table rather than chaining.

This improves the Windows self-link of LLD by 4.4% (averaged over 10
runs, with well under 1% of variance on each).

There is still some room to improve here. Two things I clearly see in
the profile:

1) This is one of the biggest stress tests for the LLVM hashing code. It
   actually consumes something like 3-4% of the link time after the
   change.
2) The way that StringRef keys are handled in the DenseMap interface is
   pretty suboptimal. We pay the price of checking for empty and
   tombstone keys when we could only possibly be looking for a normal
   key. But fixing this requires invasive API changes.

So there is still some headroom here.

Differential Revision: http://reviews.llvm.org/D10684

llvm-svn: 240871

lld/COFF/SymbolTable.h

@@ -11,9 +11,10 @@
 #define LLD_COFF_SYMBOL_TABLE_H
 
 #include "InputFiles.h"
+#include "llvm/ADT/DenseMap.h"
+#include "llvm/ADT/DenseMapInfo.h"
 #include "llvm/Support/Allocator.h"
 #include "llvm/Support/raw_ostream.h"
-#include <unordered_map>
 
 namespace llvm {
 struct LTOCodeGenerator;
@@ -90,7 +91,7 @@ private:
   std::error_code addMemberFile(Lazy *Body);
   ErrorOr<ObjectFile *> createLTOObject(llvm::LTOCodeGenerator *CG);
 
-  std::unordered_map<StringRef, Symbol *> Symtab;
+  llvm::DenseMap<StringRef, Symbol *> Symtab;
   std::vector<std::unique_ptr<InputFile>> Files;
   size_t FileIdx = 0;
   std::vector<ArchiveFile *> ArchiveFiles;