[PATCH] D46720: Refactoring BitcodeFile constructor. NFC.

[Rumeet Dhindsa via Phabricator via llvm-commits]

rdhindsa created this revision.
rdhindsa added a reviewer: ruiu.
Herald added subscribers: llvm-commits, arichardson, emaste.
Herald added a reviewer: espindola.

Instead of creating MemoryBufferRef for BitcodeFile in InputFile.cpp, this patch adds a generateMemoryBufferRef in LTO.h. This ensures that LTO processing based on LTO options is done in LTO.cpp/LTO.h files.


Repository:
  rLLD LLVM Linker

https://reviews.llvm.org/D46720

Files:
  lld/ELF/InputFiles.cpp
  lld/ELF/LTO.cpp
  lld/ELF/LTO.h


Index: lld/ELF/LTO.h
===================================================================
--- lld/ELF/LTO.h
+++ lld/ELF/LTO.h
@@ -21,8 +21,11 @@
 #ifndef LLD_ELF_LTO_H
 #define LLD_ELF_LTO_H
 
+#include "InputFiles.h"
 #include "lld/Common/LLVM.h"
+#include "lld/Common/Memory.h"
 #include "llvm/ADT/DenseSet.h"
+#include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/Support/raw_ostream.h"
 #include <memory>
@@ -57,6 +60,24 @@
   std::unique_ptr<llvm::raw_fd_ostream> IndexFile;
   llvm::StringMap<bool> ObjectToIndexFileState;
 };
+
+inline MemoryBufferRef generateMemoryBufferRef(MemoryBufferRef MB,
+                                               StringRef ArchiveName,
+                                               uint64_t OffsetInArchive) {
+  // Here we pass a new MemoryBufferRef which is identified by ArchiveName
+  // (the fully resolved path of the archive) + member name + offset of the
+  // member in the archive.
+  // ThinLTO uses the MemoryBufferRef identifier to access its internal
+  // data structures and if two archives define two members with the same name,
+  // this causes a collision which result in only one of the objects being
+  // taken into consideration at LTO time (which very likely causes undefined
+  // symbols later in the link stage).
+  MemoryBufferRef MBRef(
+      MB.getBuffer(),
+      Saver.save(ArchiveName + MB.getBufferIdentifier() +
+                 (ArchiveName.empty() ? "" : llvm::utostr(OffsetInArchive))));
+  return MBRef;
+}
 } // namespace elf
 } // namespace lld
 
Index: lld/ELF/LTO.cpp
===================================================================
--- lld/ELF/LTO.cpp
+++ lld/ELF/LTO.cpp
@@ -9,13 +9,11 @@
 
 #include "LTO.h"
 #include "Config.h"
-#include "InputFiles.h"
 #include "LinkerScript.h"
 #include "SymbolTable.h"
 #include "Symbols.h"
 #include "lld/Common/ErrorHandler.h"
 #include "lld/Common/TargetOptionsCommandFlags.h"
-#include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/Twine.h"
Index: lld/ELF/InputFiles.cpp
===================================================================
--- lld/ELF/InputFiles.cpp
+++ lld/ELF/InputFiles.cpp
@@ -1032,10 +1032,9 @@
   // this causes a collision which result in only one of the objects being
   // taken into consideration at LTO time (which very likely causes undefined
   // symbols later in the link stage).
-  MemoryBufferRef MBRef(
-      MB.getBuffer(),
-      Saver.save(ArchiveName + MB.getBufferIdentifier() +
-                 (ArchiveName.empty() ? "" : utostr(OffsetInArchive))));
+
+  MemoryBufferRef MBRef =
+      generateMemoryBufferRef(MB, ArchiveName, OffsetInArchive);
   Obj = CHECK(lto::InputFile::create(MBRef), this);
 
   Triple T(Obj->getTargetTriple());


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D46720.146202.patch
Type: text/x-patch
Size: 2807 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180510/5bb1e5a0/attachment.bin>