ELF: Add initial ThinLTO support.

[• rafael]

Sorry, but I think it is a bit too early for this.

There are just too many moving parts right now both in lld and thin lto. Even regular LTO is not complete. We are still not internalizing when producing .so files and not all tests pass on a clang bootstrap.

I still need to finish refactoring how we handle relocations and recover the performance hit we took when handling debug sections.

Can you put this on hold for 2 weeks?

[pcc]

I certainly agree that regular LTO should reach a certain level of maturity before this goes in. That's part of why I've been spending time improving LLD to the point that I can link and run Chromium with LTO before working on this change.

Anyway, happy to continue looking at regular LTO bugs for a while first if others agree that we should hold off for now.

[tejohnson]

Thanks for working on this. Saw the follow up discussion about whether it is too early, but I had a couple comments that I thought I would share now regardless. Overall looks good and pretty straightforward.

ELF/InputFiles.cpp

605

The comment sounds like the opposite of what is being done here, but I am probably misunderstanding something...if ThinLto is true then this is a ThinLTO object not a regular LTO object, and it sounds like we are making it visible to regular LTO object files by setting this flag.

ELF/LTO.cpp

295–312

add SaveTemps handling?

299

Maybe exit early above here if there are no ThinModules, so that the ThreadPool setup isn't done unnecessarily.

[davide]

I like the patch. Please hold on until Rafael finishes with relocations or general code churn and I'll take a closer look.

[pcc]

Refresh

[ruiu]

ELF/Driver.cpp

22 ↗

(On Diff #55939)

Ditto.

ELF/Driver.h

17

Do you need this?

ELF/Error.cpp

55

Even though this function is passed as std::function<> object, it should be verb rather than noun because it is a function.

ELF/Error.h

16–18

Remove blank lines.

ELF/LTO.cpp

315–319

I can see the reason why you chose to use auto here, but still I'd use real types for consistency even though it's a bit too verbose.

ELF/LTO.h

33–35

Remove blank lines.

ELF/SymbolTable.cpp

49–53

Is this what clang-format formatted?

231–234

You can write

if (auto *BC = dyn_cast<BitcodeFile>(File))
  return !BC->ThinLto;
return false;

[pcc]

• Address review comments

ELF/Driver.cpp

22 ↗

(On Diff #55939)

Removed.

ELF/Driver.h

17

Yes. A definition of LLVMContext is required for the field LinkerDriver::Context. We were previously getting the definition from LTO.h via SymbolTable.h, until I removed the #include of LTO.h to SymbolTable.cpp.

ELF/InputFiles.cpp

605

The idea with this comment was that if the regular LTO object defines a symbol, we should mark it as used if we see a ThinLTO object with an undefined reference to that symbol. But yes, it works the other way as well. I have moved this comment to isRegularLtoInputFile with a slightly better explanation.

ELF/LTO.cpp

295–312

We can most likely add that separately.

ELF/SymbolTable.cpp

49–53

Reformatted.

[• rafael]

ELF/InputFiles.h

229

I would make the name a bit more descriptive. How about hasThinLtoSummary?

ELF/LTO.cpp

28

Just to make this easier to review, can the first version be single threaded?

151

Add a comment on why thin-lto requires initializing these bits early.

168

Making this a static helper is a nice independent cleanup. Please commit and rebase.

228

This logic is mostly duplicated with the regular lto case. Can you add a helper that return S or null? It should basically return S when we need to call undefine.

294

This is duplicated with what splitCodeGen does. We should populate the passes in one place.

ELF/LTO.h

70

A more descriptive name would be nice.

ELF/SymbolTable.cpp

50

Why?

[• rafael]

ELF/LTO.cpp

74

This cause the new lld to depend on Linker::linkModules, which should really not happen.

Mehdi, you are working on having the function import pass use just the ir mover, correct? What is the next step in that?

[mehdi_amini]

Note: I haven't looked at the patch, or the LTO implementation in lld, but my take on the current state of the gold plugin is that we expose far too much in the linker. I understand that the libLTO API was not nice, but I think the solution implemented in the gold plugin is terrible because it does not expose any generic API. The proper solution should be in my opinion to have a "LTOCodeGenerator" (and/or a "ThinLTOCodeGenerator") that exposes an appropriate interface to the linker, that would be shared by lld, gold, etc.

For instance any call to "setLinkage" should never happen in a linker-specific code.

Feel free to implement it as you want in lld, but I don't want to be bound by any "external" logic as I have been in the past with the gold plugin (i.e. I'll break lld and won't try to fix it).

ELF/LTO.cpp

74

I believe the only reason I didn't go all the way was because the "Linker" handles some specific things about comdat that are not implemented in ThinLTO (we don't have comdat information in the summary). And since we don't have comdat on Darwin, I'm not use to work with them.
I don't know if Teresa has this in her TODO list.

[pcc]

The proper solution should be in my opinion to have a "LTOCodeGenerator" (and/or a "ThinLTOCodeGenerator") that exposes an appropriate interface to the linker, that would be shared by lld, gold, etc.

Maybe, but I'm not sure that we can know what the right interface should be without working implementations in multiple linkers.

I'll break lld and won't try to fix it

That doesn't really seem reasonable to me. We all have a responsibility to keep the bots green.

That said, I'm hoping to keep the API surface area used here relatively small, which should make it easier to update. One example of this is that as I mentioned before I'd like to move promotion into the compiler so that the linker doesn't need to do anything about it.

[mehdi_amini]

In D19351#420587, @pcc wrote:

The proper solution should be in my opinion to have a "LTOCodeGenerator" (and/or a "ThinLTOCodeGenerator") that exposes an appropriate interface to the linker, that would be shared by lld, gold, etc.

Maybe, but I'm not sure that we can know what the right interface should be without working implementations in multiple linkers.

There *is* an LTO implementation that is working in multiple linker through libLTO (and gold that went with a dedicated plugin).

I'll break lld and won't try to fix it

That doesn't really seem reasonable to me. We all have a responsibility to keep the bots green.

That seems reasonable, but the conclusion on my side is that I then disagree with implementing ThinLTO in lld at all at this point as it is adding duplicating code that should not be there in the first place, and will just prevent progress in LLVM (the gold-plugin is already "technical debt")

[mehdi_amini]

Just to clarify my position: ThinLTO needs some coupling with the linker on multiple aspects, if the interface is not clearly defined and the logic is not shared, it means that evolving the function importer requires to change each linker plugin implementation, duplicating the same logic, which is a no-go IMO (this is the current state of ThinLTO in LLVM with some logic unfortunately duplicated between ThinLTOCodeGenerator and the gold-plugin).

[pcc]

In D19351#420588, @joker.eph wrote:

In D19351#420587, @pcc wrote:

The proper solution should be in my opinion to have a "LTOCodeGenerator" (and/or a "ThinLTOCodeGenerator") that exposes an appropriate interface to the linker, that would be shared by lld, gold, etc.

Maybe, but I'm not sure that we can know what the right interface should be without working implementations in multiple linkers.

There *is* an LTO implementation that is working in multiple linker through libLTO (and gold that went with a dedicated plugin).

I'm mostly talking about ThinLTO. ld64 is the only linker that uses ThinLTOCodeGenerator, to my knowledge.

I'll break lld and won't try to fix it

That doesn't really seem reasonable to me. We all have a responsibility to keep the bots green.

That seems reasonable, but the conclusion on my side is that I then disagree with implementing ThinLTO in lld at all at this point as it is adding duplicating code that should not be there in the first place, and will just prevent progress in LLVM (the gold-plugin is already "technical debt")

Not having ThinLTO in lld is already preventing progress in LLVM for me. It prevents me from being able to implement the extensions I need for CFI, for example.

If you're saying that you think that it would be better to extend ThinLTOCodeGenerator with what lld/gold/etc requires, I disagree, as I think it's premature to do that, especially since it's tied to the stable libLTO interface.

Just to clarify my position: ThinLTO needs some coupling with the linker on multiple aspects, if the interface is not clearly defined and the logic is not shared, it means that evolving the function importer requires to change each linker plugin implementation, duplicating the same logic, which is a no-go IMO (this is the current state of ThinLTO in LLVM with some logic unfortunately duplicated between ThinLTOCodeGenerator and the gold-plugin).

I agree that in the long term each linker should be using some well defined interface to ThinLTO, but I think we don't know what that interface should be yet. That's part of the reason why I'm implementing this directly first.

Besides, it's not a lot of logic, and as I already mentioned, I want to keep the API surface here small.

[mehdi_amini]

I'll break lld and won't try to fix it

That doesn't really seem reasonable to me. We all have a responsibility to keep the bots green.

That seems reasonable, but the conclusion on my side is that I then disagree with implementing ThinLTO in lld at all at this point as it is adding duplicating code that should not be there in the first place, and will just prevent progress in LLVM (the gold-plugin is already "technical debt")

Not having ThinLTO in lld is already preventing progress in LLVM for me. It prevents me from being able to implement the extensions I need for CFI, for example.

It is not clear to me: why can't you implement CFI in ThinLTO without ThinLTO in lld?
Is CFI is tied to lld in particular? I thought it is in production with Gold, even though admittedly I haven't followed closely all that stuff.

If you're saying that you think that it would be better to extend ThinLTOCodeGenerator with what lld/gold/etc requires, I disagree, as I think it's premature to do that, especially since it's tied to the stable libLTO interface.

The stable libLTO interface is not going away soon AFAIK, and we'll have to live with this for some time. The LTOCodeGenerator is terrible, and the ThinLTOCodeGenerator is not any better! Except maybe that it exposes a smaller API surface, and less constrained (for instance the number of object files produced does not have to match the number of inputs).
So do I think the ThinLTOCodeGenerator should be extended? No, on the contrary, it should be made a lot thinner by refactoring it, leaving in the end only the minimum possible that I'd expect a linker plugin to be: i.e. a bridge between the information needed by the ThinLTO logic and the linker itself.
The fact that the gold-plugin was developed as a monolithic blob is unfortunate, the fact that lld didn't bother refactoring any API with the gold-plugin seems wrong to me.

Just to clarify my position: ThinLTO needs some coupling with the linker on multiple aspects, if the interface is not clearly defined and the logic is not shared, it means that evolving the function importer requires to change each linker plugin implementation, duplicating the same logic, which is a no-go IMO (this is the current state of ThinLTO in LLVM with some logic unfortunately duplicated between ThinLTOCodeGenerator and the gold-plugin).

I agree that in the long term each linker should be using some well defined interface to ThinLTO, but I think we don't know what that interface should be yet. That's part of the reason why I'm implementing this directly first.

Besides, it's not a lot of logic, and as I already mentioned, I want to keep the API surface here small.

This will necessarily put some constrains on the FunctionImporter for instance, I already hit this with the GoldPlugin. This is what I mean by "I don't want to signup for maintaining this".
Of course I could go the way the gold-plugin and lld went: just for the FunctionImporter into ThinLTOCodeGenerator, but I don't think that how LLVM is usually developed.

[pcc]

In D19351#420615, @joker.eph wrote:

I'll break lld and won't try to fix it

That doesn't really seem reasonable to me. We all have a responsibility to keep the bots green.

That seems reasonable, but the conclusion on my side is that I then disagree with implementing ThinLTO in lld at all at this point as it is adding duplicating code that should not be there in the first place, and will just prevent progress in LLVM (the gold-plugin is already "technical debt")

Not having ThinLTO in lld is already preventing progress in LLVM for me. It prevents me from being able to implement the extensions I need for CFI, for example.

It is not clear to me: why can't you implement CFI in ThinLTO without ThinLTO in lld?
Is CFI is tied to lld in particular? I thought it is in production with Gold, even though admittedly I haven't followed closely all that stuff.

CFI with regular LTO works in all linkers, but the ThinLTO version will be based on lld because of some missing features in the gold plugin interface. See this thread: https://groups.google.com/forum/#!topic/llvm-dev/OWmVaxNrIxo

If you're saying that you think that it would be better to extend ThinLTOCodeGenerator with what lld/gold/etc requires, I disagree, as I think it's premature to do that, especially since it's tied to the stable libLTO interface.

The stable libLTO interface is not going away soon AFAIK, and we'll have to live with this for some time. The LTOCodeGenerator is terrible, and the ThinLTOCodeGenerator is not any better! Except maybe that it exposes a smaller API surface, and less constrained (for instance the number of object files produced does not have to match the number of inputs).
So do I think the ThinLTOCodeGenerator should be extended? No, on the contrary, it should be made a lot thinner by refactoring it, leaving in the end only the minimum possible that I'd expect a linker plugin to be: i.e. a bridge between the information needed by the ThinLTO logic and the linker itself.
The fact that the gold-plugin was developed as a monolithic blob is unfortunate, the fact that lld didn't bother refactoring any API with the gold-plugin seems wrong to me.

It's not so much a matter of "not bothering" as the fact that it didn't really seem worth it due to the small amount of code needed, and it would just introduce another abstraction layer that people would need to understand.

But maybe there's some simple interface that we could implement now that could be shared at least between the gold plugin and lld. I suppose in the future in order to allow the interface to be used by ThinLTOCodeGenerator we may want to add caching or other features there, so it doesn't seem too unreasonable to introduce a place for those features to be added for all linkers. Let me see if I can come up with something.

[tejohnson]

In D19351#420655, @pcc wrote:

If you're saying that you think that it would be better to extend ThinLTOCodeGenerator with what lld/gold/etc requires, I disagree, as I think it's premature to do that, especially since it's tied to the stable libLTO interface.

The stable libLTO interface is not going away soon AFAIK, and we'll have to live with this for some time. The LTOCodeGenerator is terrible, and the ThinLTOCodeGenerator is not any better! Except maybe that it exposes a smaller API surface, and less constrained (for instance the number of object files produced does not have to match the number of inputs).
So do I think the ThinLTOCodeGenerator should be extended? No, on the contrary, it should be made a lot thinner by refactoring it, leaving in the end only the minimum possible that I'd expect a linker plugin to be: i.e. a bridge between the information needed by the ThinLTO logic and the linker itself.
The fact that the gold-plugin was developed as a monolithic blob is unfortunate, the fact that lld didn't bother refactoring any API with the gold-plugin seems wrong to me.

It's not so much a matter of "not bothering" as the fact that it didn't really seem worth it due to the small amount of code needed, and it would just introduce another abstraction layer that people would need to understand.

But maybe there's some simple interface that we could implement now that could be shared at least between the gold plugin and lld. I suppose in the future in order to allow the interface to be used by ThinLTOCodeGenerator we may want to add caching or other features there, so it doesn't seem too unreasonable to introduce a place for those features to be added for all linkers. Let me see if I can come up with something.

Currently the support in gold-plugin for ThinLTO is pretty minimal, as it is here with the lld patch: read the per-module indexes, combine them, launch backend threads (which do the renameModuleForThinLTO and pass down the combined index). Most of the code in the gold-plugin is the thread launching/management.

What I would like to do is to refactor some of the handling out of libLTO, as noted earlier, but want to wait until the distributed backend communication is in place.

ELF/LTO.cpp

74

For ld64/libLTO Mehdi has the support in to determine which linkonce values are needed so the lazy symbol linking is not used. However, we need that on the gold path, along with comdat handling which will need more info in the summary (added to my TODO list). I only want to do this once I have the distributed backend communication in place (D19636) so that there can be a single mechanism to communicate this and any linkage changes to the backends/importer. Then some of the handling that is in libLTO can be refactored out and used on all paths. Eventually this will lead to the function importer being able to use IRMover directly.

[pcc]

Okay, I'm putting this on hold again until more bits are ready on the thinlto side of things.

[pcc]

• Refresh, address comments

[pcc]

I have updated the patch. I just want to make sure that people are happy with the situation around the ThinLTO API. I've been working on an LTO/ThinLTO API that could be used by both the gold plugin and lld which should address Mehdi's concerns, but it will take some time until that's ready.

[mehdi_amini]

Should we close this revision? Now that the new API is in LLVM and it is targeted by D24492 ; this seems obsolete, isn't it?

ELF/Driver.h

 //===- Driver.h -------------------------------------------------*- C++ -*-===//
 //
 //                             The LLVM Linker
 //
 // This file is distributed under the University of Illinois Open Source
 // License. See LICENSE.TXT for details.
 //
 //===----------------------------------------------------------------------===//
 
 #ifndef LLD_ELF_DRIVER_H
 #define LLD_ELF_DRIVER_H
 
 #include "SymbolTable.h"
 #include "lld/Core/LLVM.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/StringSet.h"
+#include "llvm/IR/LLVMContext.h"
 #include "llvm/Option/ArgList.h"
 #include "llvm/Support/raw_ostream.h"
 
 namespace lld {
 namespace elf {
 
 extern class LinkerDriver *Driver;
 

ELF/Error.h

 //===- Error.h --------------------------------------------------*- C++ -*-===//
 //
 //                             The LLVM Linker
 //
 // This file is distributed under the University of Illinois Open Source
 // License. See LICENSE.TXT for details.
 //
 //===----------------------------------------------------------------------===//
 
 #ifndef LLD_COFF_ERROR_H
 #define LLD_COFF_ERROR_H
 
 #include "lld/Core/LLVM.h"
 
+namespace llvm {
+class DiagnosticInfo;
+}
+
 namespace lld {
 namespace elf {
 
 extern bool HasError;
 extern llvm::raw_ostream *ErrorOS;
 
 void log(const Twine &Msg);
 void warning(const Twine &Msg);

 }
 
 template <class T> T check(ErrorOr<T> EO, const Twine &Prefix) {
   if (EO)
     return std::move(*EO);
   fatal(EO.getError().message(), Prefix);
 }
 
+void handleDiag(const llvm::DiagnosticInfo &DI);
+
 } // namespace elf
 } // namespace lld
 
 #endif

ELF/Error.cpp

 //===- Error.cpp ----------------------------------------------------------===//
 //
 //                             The LLVM Linker
 //
 // This file is distributed under the University of Illinois Open Source
 // License. See LICENSE.TXT for details.
 //
 //===----------------------------------------------------------------------===//
 
 #include "Error.h"
 #include "Config.h"
 
 #include "llvm/ADT/Twine.h"
+#include "llvm/IR/DiagnosticInfo.h"
+#include "llvm/IR/DiagnosticPrinter.h"
 #include "llvm/Support/raw_ostream.h"
 
 namespace lld {
 namespace elf {
 
 bool HasError;
 llvm::raw_ostream *ErrorOS;
 
void fatal(const Twine &Msg, const Twine &Prefix) {
   fatal(Prefix + ": " + Msg);
 }
 
 void check(std::error_code EC) {
   if (EC)
     fatal(EC.message());
 }
 
+void handleDiag(const llvm::DiagnosticInfo &DI) {
+  llvm::DiagnosticPrinterRawOStream DPOS(llvm::errs());
+  DI.print(DPOS);
+  if (DI.getKind() == llvm::DS_Error)
+    exit(1);
+}
+
 } // namespace elf
 } // namespace lld

ELF/InputFiles.h

 public:
   explicit BitcodeFile(MemoryBufferRef M);
   static bool classof(const InputFile *F) { return F->kind() == BitcodeKind; }
   template <class ELFT>
   void parse(llvm::DenseSet<StringRef> &ComdatGroups);
   ArrayRef<Symbol *> getSymbols() { return Symbols; }
   static bool shouldSkip(uint32_t Flags);
   std::unique_ptr<llvm::object::IRObjectFile> Obj;
+  bool HasThinLtoSummary;
 
 private:
   std::vector<Symbol *> Symbols;
   llvm::BumpPtrAllocator Alloc;
   llvm::StringSaver Saver{Alloc};
   template <class ELFT>
   Symbol *createSymbol(const llvm::DenseSet<const llvm::Comdat *> &KeptComdats,
                        const llvm::object::IRObjectFile &Obj,

ELF/InputFiles.cpp

 //===- InputFiles.cpp -----------------------------------------------------===//
 //
 //                             The LLVM Linker
 //
 // This file is distributed under the University of Illinois Open Source
 // License. See LICENSE.TXT for details.
 //
 //===----------------------------------------------------------------------===//
 
 #include "InputFiles.h"
 #include "Driver.h"
 #include "Error.h"
 #include "InputSection.h"
 #include "SymbolTable.h"
 #include "Symbols.h"
 #include "llvm/ADT/STLExtras.h"
+#include "llvm/Bitcode/ReaderWriter.h"
 #include "llvm/CodeGen/Analysis.h"
 #include "llvm/IR/LLVMContext.h"
 #include "llvm/IR/Module.h"
 #include "llvm/Support/raw_ostream.h"
 
 using namespace llvm;
 using namespace llvm::ELF;
 using namespace llvm::object;
if (Flags & BasicSymbolRef::SF_Common) {
     const DataLayout &DL = M.getDataLayout();
     uint64_t Size = DL.getTypeAllocSize(GV->getValueType());
     return Symtab<ELFT>::X->addCommon(NameRef, Size, GV->getAlignment(),
                                       Binding, Visibility, STT_OBJECT, this);
   }
   return Symtab<ELFT>::X->addBitcode(NameRef, IsWeak, Visibility, Type,
                                      CanOmitFromDynSym, this);
 }
 
 bool BitcodeFile::shouldSkip(uint32_t Flags) {
   if (!(Flags & BasicSymbolRef::SF_Global))
     return true;
   if (Flags & BasicSymbolRef::SF_FormatSpecific)
     return true;
   return false;
 }
 
 template <class ELFT>
 void BitcodeFile::parse(DenseSet<StringRef> &ComdatGroups) {
+  HasThinLtoSummary = hasGlobalValueSummary(MB, handleDiag);
   Obj = check(IRObjectFile::create(MB, Driver->Context));
   const Module &M = Obj->getModule();
 
   DenseSet<const Comdat *> KeptComdats;
   for (const auto &P : M.getComdatSymbolTable()) {
     StringRef N = Saver.save(P.first());
     if (ComdatGroups.insert(N).second)
       KeptComdats.insert(&P.second);

ELF/LTO.h

 
 #ifndef LLD_ELF_LTO_H
 #define LLD_ELF_LTO_H
 
 #include "lld/Core/LLVM.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/ADT/StringSet.h"
 #include "llvm/IR/Module.h"
+#include "llvm/IR/ModuleSummaryIndex.h"
 #include "llvm/Linker/IRMover.h"
+#include "llvm/Target/TargetOptions.h"
+
+namespace llvm {
+class Target;
+}
 
 namespace lld {
 namespace elf {
 
 class BitcodeFile;
 class InputFile;
 
 class BitcodeCompiler {
 public:
   BitcodeCompiler();
   void add(BitcodeFile &F);
   std::vector<std::unique_ptr<InputFile>> compile();
 
 private:
+  void initLto(BitcodeFile &F);
+
+  void addLto(BitcodeFile &F);
+  void addThinLto(BitcodeFile &F);
+
   std::vector<std::unique_ptr<InputFile>> runSplitCodegen(
       const std::function<std::unique_ptr<llvm::TargetMachine>()> &TMFactory);
 
+  std::vector<std::unique_ptr<InputFile>> compileLto();
+  std::vector<std::unique_ptr<InputFile>> compileThinLto();
+  std::unique_ptr<InputFile> compileThinLtoObject(BitcodeFile *F,
+                                                  SmallString<0> &Obj);
+
+  std::unique_ptr<llvm::TargetMachine> createTargetMachine();
+
+  // Common
+  llvm::TargetOptions Options;
+  std::string TheTriple;
+  const llvm::Target *TheTarget;
+
+  // Regular LTO
+  bool HasLto = false;
   std::unique_ptr<llvm::Module> Combined;
   llvm::IRMover Mover;
-  std::vector<SmallString<0>> OwningData;
+  std::vector<SmallString<0>> Objects;
   llvm::StringSet<> InternalizedSyms;
-  std::string TheTriple;
+
+  // ThinLTO
+  llvm::ModuleSummaryIndex CombinedIndex;
+  std::vector<BitcodeFile *> ThinModules;
+  std::vector<SmallString<0>> ThinObjects;
 };
 }
 }
 
 #endif

ELF/LTO.cpp

 #include "llvm/Analysis/TargetLibraryInfo.h"
 #include "llvm/Analysis/TargetTransformInfo.h"
 #include "llvm/Bitcode/ReaderWriter.h"
 #include "llvm/CodeGen/CommandFlags.h"
 #include "llvm/CodeGen/ParallelCG.h"
 #include "llvm/IR/AutoUpgrade.h"
 #include "llvm/IR/LegacyPassManager.h"
 #include "llvm/Linker/IRMover.h"
+#include "llvm/Object/ModuleSummaryIndexObjectFile.h"
 #include "llvm/Support/StringSaver.h"
 #include "llvm/Support/TargetRegistry.h"
 #include "llvm/Target/TargetMachine.h"
 #include "llvm/Transforms/IPO.h"
 #include "llvm/Transforms/IPO/PassManagerBuilder.h"
 #include "llvm/Transforms/Utils/ModuleUtils.h"
 
 using namespace llvm;
 using namespace llvm::object;
 using namespace llvm::ELF;
 
 using namespace lld;
raw_fd_ostream OS(Config->OutputFile.str() + Suffix.str(), EC,
                     sys::fs::OpenFlags::F_None);
   check(EC);
   WriteBitcodeToFile(&M, OS, /* ShouldPreserveUseListOrder */ true);
 }
 
 // Run LTO passes.
 // Note that the gold plugin has a similar piece of code, so
 // it is probably better to move this code to a common place.
-static void runLTOPasses(Module &M, TargetMachine &TM) {
+static void runLTOPasses(Module &M, TargetMachine &TM,
+                         ModuleSummaryIndex *Summary) {
   legacy::PassManager LtoPasses;
   LtoPasses.add(createTargetTransformInfoWrapperPass(TM.getTargetIRAnalysis()));
   PassManagerBuilder PMB;
   PMB.LibraryInfo = new TargetLibraryInfoImpl(Triple(TM.getTargetTriple()));
   PMB.Inliner = createFunctionInliningPass();
   PMB.VerifyInput = PMB.VerifyOutput = !Config->DisableVerify;
   PMB.LoopVectorize = true;
   PMB.SLPVectorize = true;
   PMB.OptLevel = Config->LtoO;
+  PMB.ModuleSummary = Summary;
   PMB.populateLTOPassManager(LtoPasses);
   LtoPasses.run(M);
 
   if (Config->SaveTemps)
     saveBCFile(M, ".lto.opt.bc");
 }
 
 static bool shouldInternalize(const SmallPtrSet<GlobalValue *, 8> &Used,
                               Symbol *S, GlobalValue *GV) {
   if (S->IsUsedInRegularObj)
     return false;
 
   if (Used.count(GV))
     return false;
 
   return !S->includeInDynsym();
 }
 
 BitcodeCompiler::BitcodeCompiler()
     : Combined(new llvm::Module("ld-temp.o", Driver->Context)),
       Mover(*Combined) {}
 
+void BitcodeCompiler::add(BitcodeFile &F) {
+  initLto(F);
+  if (F.HasThinLtoSummary)
+    addThinLto(F);
+  else
+    addLto(F);
+}
+
+void BitcodeCompiler::initLto(BitcodeFile &F) {
+  if (!TheTriple.empty())
+    return;
+
+  // Initialize these fields early so that we have a Target that we can use for
+  // both regular LTO and ThinLTO.
+  Options = InitTargetOptionsFromCodeGenFlags();
+  TheTriple = getBitcodeTargetTriple(F.MB, Driver->Context);
+  std::string Msg;
+  TheTarget = TargetRegistry::lookupTarget(TheTriple, Msg);
+  if (!TheTarget)
+    fatal("target not found: " + Msg);
+}
+
+std::unique_ptr<TargetMachine> BitcodeCompiler::createTargetMachine() {
+  Reloc::Model R = Config->Pic ? Reloc::PIC_ : Reloc::Static;
+  return std::unique_ptr<TargetMachine>(
+      TheTarget->createTargetMachine(TheTriple, "", "", Options, R));
+}
+
+static Symbol *getIfDefinedInThisModule(BitcodeFile &F, Symbol *S,
+                                        uint32_t Flags) {
+  if (Flags & BasicSymbolRef::SF_Undefined)
+    return nullptr;
+  auto *B = dyn_cast<DefinedBitcode>(S->body());
+  if (!B || B->File != &F)
+    return nullptr;
+  return S;
+}
+
 static void undefine(Symbol *S) {
   replaceBody<Undefined>(S, S->body()->getName(), STV_DEFAULT, 0);
 }
 
-void BitcodeCompiler::add(BitcodeFile &F) {
+void BitcodeCompiler::addLto(BitcodeFile &F) {
+  HasLto = true;
   std::unique_ptr<IRObjectFile> Obj = std::move(F.Obj);
   std::vector<GlobalValue *> Keep;
   unsigned BodyIndex = 0;
   ArrayRef<Symbol *> Syms = F.getSymbols();
 
   Module &M = Obj->getModule();
   if (M.getDataLayoutStr().empty())
     fatal("invalid bitcode file: " + F.getName() + " has no datalayout");
 
   // Discard non-compatible debug infos if necessary.
   M.materializeMetadata();
   UpgradeDebugInfo(M);
 
   // If a symbol appears in @llvm.used, the linker is required
   // to treat the symbol as there is a reference to the symbol
   // that it cannot see. Therefore, we can't internalize.
   SmallPtrSet<GlobalValue *, 8> Used;
   collectUsedGlobalVariables(M, Used, /* CompilerUsed */ false);
 
   for (const BasicSymbolRef &Sym : Obj->symbols()) {
     uint32_t Flags = Sym.getFlags();
     GlobalValue *GV = Obj->getSymbolGV(Sym.getRawDataRefImpl());
     if (GV && GV->hasAppendingLinkage())
       Keep.push_back(GV);
     if (BitcodeFile::shouldSkip(Flags))
       continue;
-    Symbol *S = Syms[BodyIndex++];
-    if (Flags & BasicSymbolRef::SF_Undefined)
-      continue;
-    auto *B = dyn_cast<DefinedBitcode>(S->body());
-    if (!B || B->File != &F)
+    Symbol *S = getIfDefinedInThisModule(F, Syms[BodyIndex++], Flags);
+    if (!S)
       continue;
 
     // We collect the set of symbols we want to internalize here
     // and change the linkage after the IRMover executed, i.e. after
     // we imported the symbols and satisfied undefined references
     // to it. We can't just change linkage here because otherwise
     // the IRMover will just rename the symbol.
     if (GV && shouldInternalize(Used, S, GV))
for (const BasicSymbolRef &Sym : Obj->symbols()) {
 
     Keep.push_back(GV);
   }
 
   Mover.move(Obj->takeModule(), Keep,
              [](GlobalValue &, IRMover::ValueAdder) {});
 }
 
+void BitcodeCompiler::addThinLto(BitcodeFile &F) {
+  ThinModules.push_back(&F);
+
+  std::unique_ptr<IRObjectFile> Obj = std::move(F.Obj);
+  std::unique_ptr<object::ModuleSummaryIndexObjectFile> SummaryObj =
+      check(object::ModuleSummaryIndexObjectFile::create(F.MB, handleDiag));
+  CombinedIndex.mergeFrom(SummaryObj->takeIndex(), ThinModules.size());
+
+  unsigned BodyIndex = 0;
+  ArrayRef<Symbol *> Syms = F.getSymbols();
+
+  for (const BasicSymbolRef &Sym : Obj->symbols()) {
+    uint32_t Flags = Sym.getFlags();
+    if (BitcodeFile::shouldSkip(Flags))
+      continue;
+    if (Symbol *S = getIfDefinedInThisModule(F, Syms[BodyIndex++], Flags))
+      // Allow the compiled object to provide a replacement for this symbol.
+      undefine(S);
+  }
+}
+
 static void internalize(GlobalValue &GV) {
   assert(!GV.hasLocalLinkage() &&
          "Trying to internalize a symbol with local linkage!");
   GV.setLinkage(GlobalValue::InternalLinkage);
 }
 
 std::vector<std::unique_ptr<InputFile>> BitcodeCompiler::runSplitCodegen(
     const std::function<std::unique_ptr<TargetMachine>()> &TMFactory) {
   unsigned NumThreads = Config->LtoJobs;
-  OwningData.resize(NumThreads);
+  Objects.resize(NumThreads);
 
   std::list<raw_svector_ostream> OSs;
   std::vector<raw_pwrite_stream *> OSPtrs;
-  for (SmallString<0> &Obj : OwningData) {
+  for (SmallString<0> &Obj : Objects) {
     OSs.emplace_back(Obj);
     OSPtrs.push_back(&OSs.back());
   }
 
   splitCodeGen(std::move(Combined), OSPtrs, {}, TMFactory);
 
   std::vector<std::unique_ptr<InputFile>> ObjFiles;
-  for (SmallString<0> &Obj : OwningData)
+  for (SmallString<0> &Obj : Objects)
     ObjFiles.push_back(createObjectFile(
         MemoryBufferRef(Obj, "LLD-INTERNAL-combined-lto-object")));
 
   if (Config->SaveTemps)
     for (unsigned I = 0; I < NumThreads; ++I)
-      saveLtoObjectFile(OwningData[I], I, NumThreads > 1);
+      saveLtoObjectFile(Objects[I], I, NumThreads > 1);
 
   return ObjFiles;
 }
 
 // Merge all the bitcode files we have seen, codegen the result
 // and return the resulting ObjectFile.
-std::vector<std::unique_ptr<InputFile>> BitcodeCompiler::compile() {
+std::vector<std::unique_ptr<InputFile>> BitcodeCompiler::compileLto() {
+  if (!HasLto)
+    return {};
+
   TheTriple = Combined->getTargetTriple();
   for (const auto &Name : InternalizedSyms) {
     GlobalValue *GV = Combined->getNamedValue(Name.first());
     assert(GV);
     internalize(*GV);
   }
 
   if (Config->SaveTemps)
     saveBCFile(*Combined, ".lto.bc");
 
-  std::string Msg;
-  const Target *T = TargetRegistry::lookupTarget(TheTriple, Msg);
-  if (!T)
-    fatal("target not found: " + Msg);
-  TargetOptions Options = InitTargetOptionsFromCodeGenFlags();
-  Reloc::Model R = Config->Pic ? Reloc::PIC_ : Reloc::Static;
+  std::unique_ptr<TargetMachine> TM = createTargetMachine();
+  runLTOPasses(*Combined, *TM, nullptr);
 
-  auto CreateTargetMachine = [&]() {
-    return std::unique_ptr<TargetMachine>(
-        T->createTargetMachine(TheTriple, "", "", Options, R));
-  };
+  return runSplitCodegen([&]() { return createTargetMachine(); });
+}
+
+std::unique_ptr<InputFile>
+BitcodeCompiler::compileThinLtoObject(BitcodeFile *F, SmallString<0> &Obj) {
+  LLVMContext Context;
+  std::unique_ptr<Module> M = check(parseBitcodeFile(F->MB, Context));
 
-  std::unique_ptr<TargetMachine> TM = CreateTargetMachine();
-  runLTOPasses(*Combined, *TM);
+  std::unique_ptr<TargetMachine> TM = createTargetMachine();
+  runLTOPasses(*M, *TM, &CombinedIndex);
 
-  return runSplitCodegen(CreateTargetMachine);
+  raw_svector_ostream OS(Obj);
+  splitCodeGen(std::move(M), &OS, {}, [&]() { return createTargetMachine(); });
+
+  return createObjectFile(MemoryBufferRef(Obj, "LLD-INTERNAL-thinlto-object"));
+}
+
+std::vector<std::unique_ptr<InputFile>> BitcodeCompiler::compileThinLto() {
+  std::vector<std::unique_ptr<InputFile>> Result(ThinModules.size());
+  ThinObjects.resize(ThinModules.size());
+  for (unsigned I = 0, E = ThinModules.size(); I != E; ++I)
+    Result[I] = compileThinLtoObject(ThinModules[I], ThinObjects[I]);
+  return Result;
+}
+
+// Combine compilation from regular LTO and ThinLTO.
+std::vector<std::unique_ptr<InputFile>> BitcodeCompiler::compile() {
+  std::vector<std::unique_ptr<InputFile>> Objs = compileLto();
+  std::vector<std::unique_ptr<InputFile>> ThinLtoObjs = compileThinLto();
+  for (std::unique_ptr<InputFile> &Obj : ThinLtoObjs)
+    Objs.push_back(std::move(Obj));
+  return Objs;
 }

ELF/SymbolTable.h

 //===- SymbolTable.h --------------------------------------------*- C++ -*-===//
 //
 //                             The LLVM Linker
 //
 // This file is distributed under the University of Illinois Open Source
 // License. See LICENSE.TXT for details.
 //
 //===----------------------------------------------------------------------===//
 
 #ifndef LLD_ELF_SYMBOL_TABLE_H
 #define LLD_ELF_SYMBOL_TABLE_H
 
 #include "InputFiles.h"
-#include "LTO.h"
 #include "llvm/ADT/DenseMap.h"
 
 namespace lld {
 namespace elf {
+class BitcodeCompiler;
 class Lazy;
 template <class ELFT> class OutputSectionBase;
 struct Symbol;
 
 typedef llvm::CachedHash<StringRef> SymName;
 
 // SymbolTable is a bucket of all known symbols, including defined,
 // undefined, or lazy symbols (the last one is symbols in archive
 // files whose archive members are not yet loaded).
 //
 // We put all symbols of all files to a SymbolTable, and the
 // SymbolTable selects the "best" symbols if there are name
 // conflicts. For example, obviously, a defined symbol is better than
 // an undefined symbol. Or, if there's a conflict between a lazy and a
 // undefined, it'll read an archive member to read a real definition
 // to replace the lazy symbol. The logic is implemented in the
 // add*() functions, which are called by input files as they are parsed. There
 // is one add* function per symbol type.
 template <class ELFT> class SymbolTable {
   typedef typename ELFT::Sym Elf_Sym;
   typedef typename ELFT::uint uintX_t;
 
 public:
+  SymbolTable();
+  ~SymbolTable();
+
   void addFile(std::unique_ptr<InputFile> File);
   void addCombinedLtoObject();
 
   llvm::ArrayRef<Symbol *> getSymbols() const { return SymVector; }
 
   const std::vector<std::unique_ptr<ObjectFile<ELFT>>> &getObjectFiles() const {
     return ObjectFiles;
   }

ELF/SymbolTable.cpp

 // a hash table with the logic to resolve symbol name conflicts using
 // the symbol types.
 //
 //===----------------------------------------------------------------------===//
 
 #include "SymbolTable.h"
 #include "Config.h"
 #include "Error.h"
+#include "LTO.h"
 #include "Symbols.h"
 #include "llvm/Bitcode/ReaderWriter.h"
 #include "llvm/Support/StringSaver.h"
 
 using namespace llvm;
 using namespace llvm::object;
 using namespace llvm::ELF;
 
template <class ELFT> static bool isCompatible(InputFile *FileP) {
   StringRef A = F->getName();
   StringRef B = Config->Emulation;
   if (B.empty())
     B = Config->FirstElf->getName();
   error(A + " is incompatible with " + B);
   return false;
 }
 
+template <class ELFT> SymbolTable<ELFT>::SymbolTable() {}
+template <class ELFT> SymbolTable<ELFT>::~SymbolTable() {}
+
 // Add symbols in File to the symbol table.
 template <class ELFT>
 void SymbolTable<ELFT>::addFile(std::unique_ptr<InputFile> File) {
   InputFile *FileP = File.get();
   if (!isCompatible<ELFT>(FileP))
     return;
 
   // .a file
   if (auto *F = dyn_cast<ArchiveFile>(FileP)) {
     ArchiveFiles.emplace_back(cast<ArchiveFile>(File.release()));
return demangle(Sym) + " in " + getFilename(Existing->getSourceFile<ELFT>()) +
          " and " + getFilename(NewFile);
 }
 
 template <class ELFT> Symbol *SymbolTable<ELFT>::addUndefined(StringRef Name) {
   return addUndefined(Name, STB_GLOBAL, STV_DEFAULT, /*Type*/ 0,
                       /*File*/ nullptr);
 }
 
+// Returns whether this input file is a regular (non-Thin) LTO input file. We
+// treat ThinLTO input files like regular object files in order to ensure that
+// symbols defined in regular LTO object files are visible to ThinLTO object
+// files and vice versa.
+static bool isRegularLtoInputFile(InputFile *File) {
+  if (auto *BC = dyn_cast<BitcodeFile>(File))
+    return !BC->HasThinLtoSummary;
+  return false;
+}
+
 template <class ELFT>
 Symbol *SymbolTable<ELFT>::addUndefined(StringRef Name, uint8_t Binding,
                                         uint8_t StOther, uint8_t Type,
                                         InputFile *File) {
   Symbol *S;
   bool WasInserted;
   std::tie(S, WasInserted) =
       insert(Name, Type, StOther & 3, /*CanOmitFromDynSym*/ false,
-             /*IsUsedInRegularObj*/ !File || !isa<BitcodeFile>(File), File);
+             /*IsUsedInRegularObj*/ !File || !isRegularLtoInputFile(File), File);
   if (WasInserted) {
     S->Binding = Binding;
     replaceBody<Undefined>(S, Name, StOther, Type);
     cast<Undefined>(S->body())->File = File;
     return S;
   }
   if (Binding != STB_WEAK &&
       (S->body()->isShared() || S->body()->isLazy()))

 }
 
 template <class ELFT>
 Symbol *SymbolTable<ELFT>::addBitcode(StringRef Name, bool IsWeak,
                                       uint8_t StOther, uint8_t Type,
                                       bool CanOmitFromDynSym, BitcodeFile *F) {
   Symbol *S;
   bool WasInserted;
-  std::tie(S, WasInserted) = insert(Name, Type, StOther & 3, CanOmitFromDynSym,
-                                    /*IsUsedInRegularObj*/ false, F);
+  std::tie(S, WasInserted) =
+      insert(Name, Type, StOther & 3, CanOmitFromDynSym,
+             /*IsUsedInRegularObj*/ !isRegularLtoInputFile(F), F);
   int Cmp =
       compareDefinedNonCommon(S, WasInserted, IsWeak ? STB_WEAK : STB_GLOBAL);
   if (Cmp > 0)
     replaceBody<DefinedBitcode>(S, Name, StOther, Type, F);
   else if (Cmp == 0)
     reportDuplicate(S->body(), F);
   return S;
 }

test/ELF/lto/Inputs/thinlto.ll

+target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+define void @foo() {
+  ret void
+}

test/ELF/lto/thinlto.ll

+; RUN: llvm-as -o %t1.o %s
+; RUN: llvm-as -o %t2.o %p/Inputs/thinlto.ll
+
+; RUN: opt -o %t1-thin.o -module-summary %s
+; RUN: opt -o %t2-thin.o -module-summary %p/Inputs/thinlto.ll
+
+; Functions cannot be imported across the LTO/ThinLTO boundary.
+
+; RUN: ld.lld -m elf_x86_64 -o %t-thin1 %t1-thin.o %t2.o
+; RUN: llvm-nm %t-thin1 | FileCheck --check-prefix=CHECK-NOIMPORT-SYM %s
+; RUN: llvm-objdump -d %t-thin1 | FileCheck --check-prefix=CHECK-NOIMPORT-OBJ %s
+
+; RUN: ld.lld -m elf_x86_64 -o %t-thin2 %t1.o %t2-thin.o
+; RUN: llvm-nm %t-thin2 | FileCheck --check-prefix=CHECK-NOIMPORT-SYM %s
+; RUN: llvm-objdump -d %t-thin2 | FileCheck --check-prefix=CHECK-NOIMPORT-OBJ %s
+
+; CHECK-NOIMPORT-SYM-DAG: _start
+; CHECK-NOIMPORT-SYM-DAG: foo
+
+; CHECK-NOIMPORT-OBJ: callq
+
+; foo() should have been imported into t1.
+
+; RUN: ld.lld -m elf_x86_64 -o %t %t1-thin.o %t2-thin.o
+; RUN: llvm-objdump -d %t | FileCheck --check-prefix=CHECK-IMPORT-OBJ %s
+
+; CHECK-IMPORT-OBJ: _start:
+; CHECK-IMPORT-OBJ-NEXT: retq
+
+target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+declare void @foo()
+
+define void @_start() {
+  call void @foo()
+  ret void
+}