[ThinLTO] Emit files for distributed builds for all modules

[tejohnson]

Summary

With the new LTO API in r278338, we stopped emitting the individual
index files and imports files for some modules in the distributed backend
case (thinlto-index-only plugin option).

Specifically, this is when the linker decides not to include a module in the
link, because it was in an archive library and did not have a strong
reference to it. Not creating the expected output files makes the
distributed build system implementation more difficult, in terms of
checking for the expected outputs of the thin link, and scheduling the
backend jobs. To address this, the gold-plugin will write dummy empty
.thinlto.bc and .imports files for modules not included in the link
(which LTO never sees).

Augmented a gold v1.12+ test, since that version of gold has the handling
for notifying on modules not being included in the link.

[mehdi_amini]

tools/llvm-lto2/llvm-lto2.cpp

147

Looks like we stepped on each other feet (D23681)

[mehdi_amini]

They were no longer being emitted for files that didn't contain a module index (e.g. when they had inline assembly, since we can't currently safely import), because the new API only added them to the ThinLTO backend based on the presence of a module index. They were instead added as regular LTO files, and were all expected to be merged into a single LTO module. This is problematic because the distributed build system will not know how to create backend actions for those files.

I do not necessarily see this as a "bug" right now: we need a coherent story for the intended behavior here. If a file is not meant to go to to the ThinLTO backend, then it shouldn't go there. It seems to me that the real issue you're tackling is that we don't emit any summary in the bitcode for files that have inline asm, and thus they are not detected as "ThinLTO" files and not sent to the right backend.
I believe the "right" fix for this is to change the way we detect if a file was produced with -flto=thin to detect this file (the "easy" way may be to emit an empty summary?).

It does not totally solve the question about how to do with inputs that were not build with -flto=thin but -flto=full. It does not seem right to me to send these to the ThinLTO backend. You can start by consider this as "unsupported" by your current distributed build system integration, and then built the mechanism that would allow the build system to deal with this if needed.

Note also that the class LTO is doing too much right now: if the RegularLTOState was moved to a separate entity in way that it could be injected like the ThinLTOBackend, all of this could be handled/overridden by the client (I mentioned this lack of layering in early reviews). The "ForceThinLTO" flag in the config seems to me to be a workaround for this.

[tejohnson]

In D23680#519874, @mehdi_amini wrote:

They were no longer being emitted for files that didn't contain a module index (e.g. when they had inline assembly, since we can't currently safely import), because the new API only added them to the ThinLTO backend based on the presence of a module index. They were instead added as regular LTO files, and were all expected to be merged into a single LTO module. This is problematic because the distributed build system will not know how to create backend actions for those files.

I do not necessarily see this as a "bug" right now: we need a coherent story for the intended behavior here. If a file is not meant to go to to the ThinLTO backend, then it shouldn't go there. It seems to me that the real issue you're tackling is that we don't emit any summary in the bitcode for files that have inline asm, and thus they are not detected as "ThinLTO" files and not sent to the right backend.
I believe the "right" fix for this is to change the way we detect if a file was produced with -flto=thin to detect this file (the "easy" way may be to emit an empty summary?).

Possible, but:

It does not totally solve the question about how to do with inputs that were not build with -flto=thin but -flto=full. It does not seem right to me to send these to the ThinLTO backend. You can start by consider this as "unsupported" by your current distributed build system integration, and then built the mechanism that would allow the build system to deal with this if needed.

For now we can handle this unsupported case by treating all the IR modules (regardless of how they were produced) through the ThinLTO compilation model. I am happy to put this under a different option rather than keying off of thinlto-index-only if you'd prefer, would that be better?

Note also that the class LTO is doing too much right now: if the RegularLTOState was moved to a separate entity in way that it could be injected like the ThinLTOBackend, all of this could be handled/overridden by the client (I mentioned this lack of layering in early reviews). The "ForceThinLTO" flag in the config seems to me to be a workaround for this.

That may be a better longer term change. In the meantime this is a simple way to reverse the regression (before the new API, the gold-plugin keyed off of the "thinlto" plugin option, not the presence of a module index section). I could put a FIXME there if that would help. Does that sound ok?

[tejohnson]

Address feedback from earlier review:
1) Emit empty summaries for files without any GVs that can be imported
when in ThinLTO mode. This ensures that LTO treats them as ThinLTO
inputs and schedules ThinLTO backends for them. It required a few
fixes to handle the empty summaries.
2) Per offline discussion with Mehdi, for the case where the linker
is not going to include some of the modules in the final link, in
the gold-plugin client itself write the dummy empty files expected by the
distributed build system for all modules.

[mehdi_amini]

lib/Bitcode/Reader/BitcodeReader.cpp

6111 ↗

(On Diff #71952)

Can you commit this as a separate patch? This is mostly unrelated to the distributed build.

[tejohnson]

lib/Bitcode/Reader/BitcodeReader.cpp

6111 ↗

(On Diff #71952)

It is related to the change to always emit a summary when compiling for ThinLTO. Maybe I should split that portion (along with the corresponding fixes like this one) out into a separate patch. Is that what you meant? It fixes part of the distributed build issue.

[pcc]

tools/gold/gold-plugin.cpp

812

I am not sure if this is needed, but even if it is, can't this be done inside lib/LTO?

[tejohnson]

tools/gold/gold-plugin.cpp

812

This is needed because the distributed build system (in this case Bazel) wants to check that its expected outputs were generated. It doesn't know what the linker decided to include in the final link or not. This was a regression from the earlier behavior before we moved to the new LTO API.

My earlier version of the patch had this fix in lib/LTO, but Mehdi expressed a preference (in an offline discussion) to move this into the client.

[mehdi_amini]

lib/Bitcode/Reader/BitcodeReader.cpp

6111 ↗

(On Diff #71952)

It also change the behavior outside of distributed build right?
It will make files that we didn't include in ThinLTO before, part of the ThinLTO partitions now.

[mehdi_amini]

tools/gold/gold-plugin.cpp

812

Right: it seems "client specific" as it is a constraint that comes from Bazel.

[tejohnson]

lib/Bitcode/Reader/BitcodeReader.cpp

6111 ↗

(On Diff #71952)

Yes. Ok, will split that whole part out into a separate patch. This patch will end up just being the changes to gold-plugin.cc, test/tools/gold/X86/v1.12/thinlto_emit_linked_objects.ll, and the refactoring of getThinLTOOutputFile in LTO.

tools/gold/gold-plugin.cpp

812

Although note that Bazel is independent of gold. It just happens that we build with using the gold linker and the Bazel distributed build system.

[pcc]

tools/gold/gold-plugin.cpp

812

When you say "It doesn't know what the linker decided to include" are you referring to which archive members the linker chose?

So the regression is that the distributed build is missing non-ThinLTO objects from archives, and the fix is to create empty .thinlto.bc files to cause the build system to include the non-ThinLTO objects in the final link?

Or am I misunderstanding?

[tejohnson]

tools/gold/gold-plugin.cpp

812

Correct, it is to deal with the fact that with archives (--start-lib/--end-lib in our case), gold will not include some of the files in the final link. Those are not passed to the backend and no ThinLTO outputs are created for them.

We do emit the list of files to include in the final link (into the thinlto_linked_objects_file, which is an optional file provided to the thinlto-index-only= option), and that ends up informing the final link done by Bazel (essentially passed in via the @ linker option).

However, the issue here is with the way Bazel does sanity checking of expected outputs - all it knows when it kicks off the ThinLink action is that it is passing a set of object (IR) files to the Thin Link action, and each action needs to be told what output files it should bring back. The lower level job handling checks that these expected outputs are created and fetches them back. With the current LTO code, that contract is being broken, because not all expected outputs are being created.

[mehdi_amini]

tools/gold/gold-plugin.cpp

812

Although note that Bazel is independent of gold. It just happens that we build with using the gold linker and the Bazel distributed build system.

Right, I'm not convinced it belongs here entirely :)

My understanding is that it is very targeted: this operates under the assumptions that:

1. The build system has a list of all the input to the linker (including archive members)
2. The build system expects the linker to produces 1-1 output for each input.

So it is about both archive members not chosen by the linker, and input files that are not ThinLTO.
I don't think the latter case is handled though, it seems to be relying on every input being built with -flto=thin (or I missed a piece somewhere, how would an object file be handled?)

[tejohnson]

tools/gold/gold-plugin.cpp

812

So it is about both archive members not chosen by the linker, and input files that are not ThinLTO.
I don't think the latter case is handled though, it seems to be relying on every input being built with -flto=thin
(or I missed a piece somewhere, how would an object file be handled?)

We know which compile actions are ThinLTO actions and set up the expected inputs and outputs that way. In cases where there is e.g. a native object, there isn't a ThinLTO output scheduled to be returned from the ThinLink. So the part of this patch that always generates a summary when compiling -flto=thin fixes the issue where we were not treating these as ThinLTO inputs in the ThinLink.

For the archive members not included in the final link. the issue is that when we set up the ThinLink action, we know which inputs are ThinLTO inputs, and need to specify which outputs should be expected and brought back. That has no knowledge of the linker behavior and which inputs it will ultimately select.

[mehdi_amini]

tools/gold/gold-plugin.cpp

812

So if I have a project that depends on a vendor supplied library, it is up to the person configuring the project to instruct Bazel about the ThinLTO member inside this archive?

[pcc]

tools/gold/gold-plugin.cpp

812

I see. So my next question is, if Bazel knows the names of the expected output files, can it (or some other component of the system such as a wrapper script) not be taught to touch those files by itself before running the initial linker pass?

I can appreciate if the answer is "not easily". I'm just trying to get a sense of the right tradeoff here.

[tejohnson]

tools/gold/gold-plugin.cpp

812

So if I have a project that depends on a vendor supplied library, it is up to the person configuring the project to instruct Bazel about the ThinLTO member inside this archive?

There are a few limitations that would currently prevent this from working well with the build system right now. That use case would require some more work beyond this, at least to get the backend job distributed properly. We currently expect to compile all ThinLTO code from source.

[tejohnson]

tools/gold/gold-plugin.cpp

812

I can appreciate if the answer is "not easily". I'm just trying to get a sense of the right tradeoff here.

I don't think this is easy given the way things are architected. But it also prevents error checking that we did in fact run the thin link and get outputs.

[tejohnson]

Moved the part of this patch that handles always emitting a summary
section for files compiled -flto=thin into a separate patch (D24779).

This part deals with ensuring the distributed build system gets back
expected outputs for the files it compiled in ThinLTO mode.

[tejohnson]

pcc, are you ok with keeping this here rather than in LTO? The advantage is that LTO doesn't need to know about files the linker decided to exclude, just those to be built with LTO.

[mehdi_amini]

I'm fine with the patch as it is now.
Let's just wait for Peter to confirm.

[pcc]

tools/gold/gold-plugin.cpp

812

But it also prevents error checking that we did in fact run the thin link and get outputs.

You could do that by reading the LinkedObjectsFile, no?

But okay, I suppose this is fine since it doesn't preclude a better implementation on the bazel side later.

[tejohnson]

tools/gold/gold-plugin.cpp

812

You could do that by reading the LinkedObjectsFile, no?

That's difficult since where the outputs are checked is low level generic job management functionality, and not cognizant of the fact that this is ThinLTO (I looked at this initially).

But okay, I suppose this is fine since it doesn't preclude a better implementation on the bazel side later.

Ok thanks.

[tejohnson]

r282100

include/llvm/LTO/Config.h

struct Config {
   TargetOptions Options;
   std::vector<std::string> MAttrs;
   Reloc::Model RelocModel = Reloc::PIC_;
   CodeModel::Model CodeModel = CodeModel::Default;
   CodeGenOpt::Level CGOptLevel = CodeGenOpt::Default;
   unsigned OptLevel = 2;
   bool DisableVerify = false;
 
+  /// True if all input files should be handed to a ThinLTO backend, and
+  /// not inferred from presence of module summary.
+  bool ForceThinLTO = false;
+
   /// Setting this field will replace target triples in input files with this
   /// triple.
   std::string OverrideTriple;
 
   /// Setting this field will replace unspecified target triples in input files
   /// with this triple.
   std::string DefaultTriple;
 
struct Config {
   Config() {}
   // FIXME: Remove once MSVC can synthesize move ops.
   Config(Config &&X)
       : CPU(std::move(X.CPU)), Features(std::move(X.Features)),
         Options(std::move(X.Options)), MAttrs(std::move(X.MAttrs)),
         RelocModel(std::move(X.RelocModel)), CodeModel(std::move(X.CodeModel)),
         CGOptLevel(std::move(X.CGOptLevel)), OptLevel(std::move(X.OptLevel)),
         DisableVerify(std::move(X.DisableVerify)),
+        ForceThinLTO(std::move(X.ForceThinLTO)),
         OverrideTriple(std::move(X.OverrideTriple)),
         DefaultTriple(std::move(X.DefaultTriple)),
         ShouldDiscardValueNames(std::move(X.ShouldDiscardValueNames)),
         DiagHandler(std::move(X.DiagHandler)),
         ResolutionFile(std::move(X.ResolutionFile)),
         PreOptModuleHook(std::move(X.PreOptModuleHook)),
         PostPromoteModuleHook(std::move(X.PostPromoteModuleHook)),
         PostInternalizeModuleHook(std::move(X.PostInternalizeModuleHook)),
         PostImportModuleHook(std::move(X.PostImportModuleHook)),
         PostOptModuleHook(std::move(X.PostOptModuleHook)),
         PreCodeGenModuleHook(std::move(X.PreCodeGenModuleHook)),
         CombinedIndexHook(std::move(X.CombinedIndexHook)) {}
   // FIXME: Remove once MSVC can synthesize move ops.
   Config &operator=(Config &&X) {
     CPU = std::move(X.CPU);
     Features = std::move(X.Features);
     Options = std::move(X.Options);
     MAttrs = std::move(X.MAttrs);
     RelocModel = std::move(X.RelocModel);
     CodeModel = std::move(X.CodeModel);
     CGOptLevel = std::move(X.CGOptLevel);
     OptLevel = std::move(X.OptLevel);
     DisableVerify = std::move(X.DisableVerify);
+    ForceThinLTO = std::move(X.ForceThinLTO);
     OverrideTriple = std::move(X.OverrideTriple);
     DefaultTriple = std::move(X.DefaultTriple);
     ShouldDiscardValueNames = std::move(X.ShouldDiscardValueNames);
     DiagHandler = std::move(X.DiagHandler);
     ResolutionFile = std::move(X.ResolutionFile);
     PreOptModuleHook = std::move(X.PreOptModuleHook);
     PostPromoteModuleHook = std::move(X.PostPromoteModuleHook);
     PostInternalizeModuleHook = std::move(X.PostInternalizeModuleHook);

include/llvm/LTO/LTO.h

public:
   LTO(Config Conf, ThinBackend Backend = nullptr,
       unsigned ParallelCodeGenParallelismLevel = 1);
 
   /// Add an input file to the LTO link, using the provided symbol resolutions.
   /// The symbol resolutions must appear in the enumeration order given by
   /// InputFile::symbols().
   Error add(std::unique_ptr<InputFile> Obj, ArrayRef<SymbolResolution> Res);
 
+  /// Add an input file that the linker decided not to include in the link.
+  /// This could happen for objects from archive libraries that weren't
+  /// strongly referenced. Currently this is used to ensure they get
+  /// (empty) individual module index files, so that a distributed build
+  /// system can validate the list of expected outputs.
+  Error addNotLinkedModule(StringRef ModulePath);
+
   /// Returns an upper bound on the number of tasks that the client may expect.
   /// This may only be called after all IR object files have been added. For a
   /// full description of tasks see LTOBackend.h.
   unsigned getMaxTasks() const;
 
   /// Runs the LTO pipeline. This function calls the supplied AddOutput function
   /// to add native object files to the link.
   Error run(AddOutputFn AddOutput);
enum : unsigned {
       /// external reference, and therefore cannot be internalized.
       External = -2u,
     };
   };
 
   // Global mapping from mangled symbol names to resolutions.
   StringMap<GlobalResolution> GlobalResolutions;
 
+  // List of modules that the linker decided not to include in the link.
+  std::vector<StringRef> NotLinkedModules;
+
   void writeToResolutionFile(InputFile *Input, ArrayRef<SymbolResolution> Res);
 
   void addSymbolToGlobalRes(object::IRObjectFile *Obj,
                             SmallPtrSet<GlobalValue *, 8> &Used,
                             const InputFile::Symbol &Sym, SymbolResolution Res,
                             unsigned Partition);
 
   Error addRegularLTO(std::unique_ptr<InputFile> Input,

lib/LTO/LTO.cpp

Error LTO::add(std::unique_ptr<InputFile> Input,
   collectUsedGlobalVariables(M, Used, /*CompilerUsed*/ false);
 
   if (!Conf.OverrideTriple.empty())
     M.setTargetTriple(Conf.OverrideTriple);
   else if (M.getTargetTriple().empty())
     M.setTargetTriple(Conf.DefaultTriple);
 
   MemoryBufferRef MBRef = Input->Obj->getMemoryBufferRef();
-  bool HasThinLTOSummary = hasGlobalValueSummary(MBRef, Conf.DiagHandler);
 
-  if (HasThinLTOSummary)
+  if (Conf.ForceThinLTO || hasGlobalValueSummary(MBRef, Conf.DiagHandler))
     return addThinLTO(std::move(Input), Res);
   else
     return addRegularLTO(std::move(Input), Res);
 }
 
 // Add a regular LTO object to the link.
 Error LTO::addRegularLTO(std::unique_ptr<InputFile> Input,
                          ArrayRef<SymbolResolution> Res) {
if (Res.Prevailing && GV)
           MBRef.getBufferIdentifier();
   }
   assert(ResI == Res.end());
 
   ThinLTO.ModuleMap[MBRef.getBufferIdentifier()] = MBRef;
   return Error();
 }
 
+Error LTO::addNotLinkedModule(StringRef ModulePath) {
+  NotLinkedModules.push_back(ModulePath);
+  return Error();
+}
+
 unsigned LTO::getMaxTasks() const {
   CalledGetMaxTasks = true;
   return RegularLTO.ParallelCodeGenParallelismLevel + ThinLTO.ModuleMap.size();
 }
 
 Error LTO::run(AddOutputFn AddOutput) {
   // Invoke regular LTO if there was a regular LTO module to start with,
   // or if there are any hooks that the linker may have used to add
ThinBackendProc(Config &Conf, ModuleSummaryIndex &CombinedIndex,
                   StringMap<GVSummaryMapTy> &ModuleToDefinedGVSummaries)
       : Conf(Conf), CombinedIndex(CombinedIndex), AddOutput(AddOutput),
         ModuleToDefinedGVSummaries(ModuleToDefinedGVSummaries) {}
 
   virtual ~ThinBackendProc() {}
   virtual Error start(unsigned Task, MemoryBufferRef MBRef,
                       const FunctionImporter::ImportMapTy &ImportList,
                       MapVector<StringRef, MemoryBufferRef> &ModuleMap) = 0;
+  virtual Error startNotLinkedFileHandling(StringRef ModulePath) = 0;
   virtual Error wait() = 0;
 };
 
 class InProcessThinBackend : public ThinBackendProc {
   ThreadPool BackendThreadPool;
 
   Optional<Error> Err;
   std::mutex ErrMu;
BackendThreadPool.async(
               Err = std::move(E);
           }
         },
         MBRef, std::ref(CombinedIndex), std::ref(ImportList),
         std::ref(ModuleToDefinedGVSummaries[ModulePath]), std::ref(ModuleMap));
     return Error();
   }
 
+  // For an in process backend we ignore any modules the linker decided
+  // not to include in the link.
+  Error startNotLinkedFileHandling(StringRef ModulePath) override {
+    return Error();
+  }
+
   Error wait() override {
     BackendThreadPool.wait();
     if (Err)
       return std::move(*Err);
     else
       return Error();
   }
 };
if (!ParentPath.empty()) {
       // Make sure the new directory exists, creating it if necessary.
       if (std::error_code EC = llvm::sys::fs::create_directories(ParentPath))
         llvm::errs() << "warning: could not create directory '" << ParentPath
                      << "': " << EC.message() << '\n';
     }
     return NewPath.str();
   }
 
-  Error start(unsigned Task, MemoryBufferRef MBRef,
+  Error WriteIndexFiles(StringRef ModulePath,
                         const FunctionImporter::ImportMapTy &ImportList,
-              MapVector<StringRef, MemoryBufferRef> &ModuleMap) override {
-    StringRef ModulePath = MBRef.getBufferIdentifier();
+                        bool IsLinked) {
     std::string NewModulePath =
         getThinLTOOutputFile(ModulePath, OldPrefix, NewPrefix);
 
     std::error_code EC;
-    if (!LinkedObjectsFileName.empty()) {
+    if (IsLinked && !LinkedObjectsFileName.empty()) {
       if (!LinkedObjectsFile) {
         LinkedObjectsFile = llvm::make_unique<raw_fd_ostream>(
             LinkedObjectsFileName, EC, sys::fs::OpenFlags::F_None);
         if (EC)
           return errorCodeToError(EC);
       }
       *LinkedObjectsFile << NewModulePath << '\n';
     }
 
     std::map<std::string, GVSummaryMapTy> ModuleToSummariesForIndex;
+    if (IsLinked)
       gatherImportedSummariesForModule(ModulePath, ModuleToDefinedGVSummaries,
                                        ImportList, ModuleToSummariesForIndex);
 
     raw_fd_ostream OS(NewModulePath + ".thinlto.bc", EC,
                       sys::fs::OpenFlags::F_None);
     if (EC)
       return errorCodeToError(EC);
     WriteIndexToFile(CombinedIndex, OS, &ModuleToSummariesForIndex);
 
     if (ShouldEmitImportsFiles)
       return errorCodeToError(
           EmitImportsFiles(ModulePath, NewModulePath + ".imports", ImportList));
     return Error();
   }
 
+  Error start(unsigned Task, MemoryBufferRef MBRef,
+              const FunctionImporter::ImportMapTy &ImportList,
+              MapVector<StringRef, MemoryBufferRef> &ModuleMap) override {
+    return WriteIndexFiles(MBRef.getBufferIdentifier(), ImportList,
+                           /* IsLinked = */ true);
+  }
+
+  // For a distributed build we ensure that the expected output files
+  // are created even for those files the linker decided not to include.
+  Error startNotLinkedFileHandling(StringRef ModulePath) override {
+    FunctionImporter::ImportMapTy EmptyImportList;
+    return WriteIndexFiles(ModulePath, EmptyImportList,
+                           /* IsLinked = */ false);
+  }
+
   Error wait() override { return Error(); }
 };
 
 ThinBackend lto::createWriteIndexesThinBackend(std::string OldPrefix,
                                                std::string NewPrefix,
                                                bool ShouldEmitImportsFiles,
                                                std::string LinkedObjectsFile) {
   return [=](Config &Conf, ModuleSummaryIndex &CombinedIndex,
for (auto &Mod : ThinLTO.ModuleMap) {
     if (Error E = BackendProc->start(Task, Mod.second, ImportLists[Mod.first],
                                      ThinLTO.ModuleMap))
       return E;
 
     ++Task;
     ++Partition;
   }
 
+  for (auto ModPath : NotLinkedModules) {
+    if (Error E = BackendProc->startNotLinkedFileHandling(ModPath))
+      return E;
+  }
+
   return BackendProc->wait();
 }

test/ThinLTO/X86/Inputs/emit_imports.ll

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

test/ThinLTO/X86/Inputs/empty.ll

+target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"

test/ThinLTO/X86/emit_imports.ll

 ; RUN: opt -module-summary %s -o %t1.bc
 ; RUN: opt -module-summary %p/Inputs/emit_imports.ll -o %t2.bc
-; RUN: llvm-lto -thinlto-action=thinlink -o %t.index.bc %t1.bc %t2.bc
-; RUN: llvm-lto -thinlto-action=emitimports -thinlto-index %t.index.bc %t1.bc %t2.bc
+; Include a file without a module summary index, to ensure that the expected
+; output files are created regardless, for a distributed build system.
+; RUN: opt %p/Inputs/empty.ll -o %t3.bc
+; RUN: rm -f %t3.bc.imports
+; RUN: llvm-lto -thinlto-action=thinlink -o %t.index.bc %t1.bc %t2.bc %t3.bc
+; RUN: llvm-lto -thinlto-action=emitimports -thinlto-index %t.index.bc %t1.bc %t2.bc %t3.bc
 
 ; The imports file for this module contains the bitcode file for
 ; Inputs/emit_imports.ll
 ; RUN: cat %t1.bc.imports | count 1
 ; RUN: cat %t1.bc.imports | FileCheck %s --check-prefix=IMPORTS1
 ; IMPORTS1: emit_imports.ll.tmp2.bc
 
 ; The imports file for Input/emit_imports.ll is empty as it does not import anything.
 ; RUN: cat %t2.bc.imports | count 0
 
+; The imports file for Input/empty.ll is empty but should exist.
+; RUN: cat %t3.bc.imports | count 0
+
+; RUN: rm -f %t3.bc.thinlto.bc %t3.bc.imports
+; RUN: llvm-lto2 %t1.bc %t2.bc %t3.bc -o %t.o -save-temps \
+; RUN:     -thinlto-index-only \
+; RUN:     -r=%t1.bc,g, \
+; RUN:     -r=%t1.bc,f,px \
+; RUN:     -r=%t2.bc,g,px
+; RUN: ls %t3.bc.thinlto.bc
+; RUN: ls %t3.bc.imports
+
+target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
 declare void @g(...)
 
 define void @f() {
 entry:
   call void (...) @g()
   ret void
 }

test/tools/gold/X86/thinlto_emit_imports.ll

 ; Generate summary sections and test gold handling.
 ; RUN: opt -module-summary %s -o %t.o
 ; RUN: opt -module-summary %p/Inputs/thinlto.ll -o %t2.o
+; Include a file without a module summary index, to ensure that the expected
+; output files are created regardless, for a distributed build system.
+; RUN: opt %p/Inputs/thinlto_empty.ll -o %t3.o
 
 ; Ensure gold generates imports files if requested for distributed backends.
+; RUN: rm -f %t3.o.imports %t3.o.thinlto.bc
 ; RUN: %gold -plugin %llvmshlibdir/LLVMgold.so \
 ; RUN:    --plugin-opt=thinlto \
 ; RUN:    --plugin-opt=thinlto-index-only \
 ; RUN:    --plugin-opt=thinlto-emit-imports-files \
-; RUN:    -shared %t.o %t2.o -o %t3
+; RUN:    -shared %t.o %t2.o %t3.o -o %t4
 
 ; The imports file for this module contains the bitcode file for
 ; Inputs/thinlto.ll
 ; RUN: cat %t.o.imports | count 1
 ; RUN: cat %t.o.imports | FileCheck %s --check-prefix=IMPORTS1
 ; IMPORTS1: test/tools/gold/X86/Output/thinlto_emit_imports.ll.tmp2.o
 
 ; The imports file for Input/thinlto.ll is empty as it does not import anything.
 ; RUN: cat %t2.o.imports | count 0
 
+; These files should be created even for the input without a summary index.
+; RUN: ls %t3.o.imports
+; RUN: ls %t3.o.thinlto.bc
+
 declare void @g(...)
 
 define void @f() {
 entry:
   call void (...) @g()
   ret void
 }

test/tools/gold/X86/v1.12/thinlto_emit_linked_objects.ll

 ; First generate bitcode with a module summary index for each file
 ; RUN: opt -module-summary %s -o %t.o
 ; RUN: opt -module-summary %p/Inputs/thinlto_emit_linked_objects.ll -o %t2.o
 
 ; Next do the ThinLink step, specifying thinlto-index-only so that the gold
 ; plugin exits after generating individual indexes. The objects the linker
 ; decided to include in the link should be emitted into the file specified
 ; after 'thinlto-index-only='. In this version of the test, only %t.o will
 ; be included in the link, and not %t2.o since it is within
 ; a library (--start-lib/--end-lib pair) and not strongly referenced.
 ; Note that the support for detecting this is in gold v1.12.
+; RUN: rm -f %t.o.thinlto.bc
+; RUN: rm -f %t2.o.thinlto.bc
+; RUN: rm -f %t.o.imports
+; RUN: rm -f %t2.o.imports
 ; RUN: %gold -plugin %llvmshlibdir/LLVMgold.so \
 ; RUN:    --plugin-opt=thinlto \
 ; RUN:    --plugin-opt=thinlto-index-only=%t3 \
+; RUN:    --plugin-opt=thinlto-emit-imports-files \
 ; RUN:    -m elf_x86_64 \
 ; RUN:    -o %t4 \
 ; RUN:    %t.o \
 ; RUN:    --start-lib %t2.o --end-lib
 
+; Ensure that the expected output files are created, even for the file
+; the linker decided not to include in the link.
+; RUN: ls %t.o.thinlto.bc
+; RUN: ls %t2.o.thinlto.bc
+; RUN: ls %t.o.imports
+; RUN: ls %t2.o.imports
+
 ; RUN: cat %t3 | FileCheck %s
 ; CHECK: thinlto_emit_linked_objects.ll.tmp.o
 ; CHECK-NOT: thinlto_emit_linked_objects.ll.tmp2.o
 
 target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
 target triple = "x86_64-unknown-linux-gnu"
 
 define i32 @main() {
 entry:
   ret i32 0
 }

tools/gold/gold-plugin.cpp

static void addModule(LTO &Lto, claimed_file &F, const void *View) {
   MemoryBufferRef BufferRef(StringRef((const char *)View, F.filesize), F.name);
   Expected<std::unique_ptr<InputFile>> ObjOrErr = InputFile::create(BufferRef);
 
   if (!ObjOrErr)
     message(LDPL_FATAL, "Could not read bitcode from file : %s",
             toString(ObjOrErr.takeError()).c_str());
 
   InputFile &Obj = **ObjOrErr;
-  bool HasThinLTOSummary =
+  bool IsThinLTO =
+      options::thinlto_index_only ||
       hasGlobalValueSummary(Obj.getMemoryBufferRef(), diagnosticHandler);
 
   unsigned SymNum = 0;
   std::vector<SymbolResolution> Resols(F.syms.size());
   for (auto &ObjSym : Obj.symbols()) {
     ld_plugin_symbol &Sym = F.syms[SymNum];
     SymbolResolution &R = Resols[SymNum];
     ++SymNum;
case LDPR_PREVAILING_DEF_IRONLY_EXP:
         R.VisibleToRegularObj = true;
       break;
     }
 
     if (Resolution != LDPR_RESOLVED_DYN && Resolution != LDPR_UNDEF &&
         (IsExecutable || !Res.DefaultVisibility))
       R.FinalDefinitionInLinkageUnit = true;
 
-    if ((ObjSym.getFlags() & object::BasicSymbolRef::SF_Common) &&
-        !HasThinLTOSummary) {
+    if ((ObjSym.getFlags() & object::BasicSymbolRef::SF_Common) && !IsThinLTO) {
       // We ignore gold's resolution for common symbols. A common symbol with
       // the correct size and alignment is added to the module by the pre-opt
       // module hook if any common symbol prevailed.
       CommonResolution &CommonRes = Commons[ObjSym.getIRName()];
       if (R.Prevailing) {
         CommonRes.Prevailing = true;
         CommonRes.VisibleToRegularObj = R.VisibleToRegularObj;
       }
else
       ParallelCodeGenParallelismLevel = options::Parallelism;
   }
   if (options::thinlto_index_only) {
     std::string OldPrefix, NewPrefix;
     getThinLTOOldAndNewPrefix(OldPrefix, NewPrefix);
     Backend = createWriteIndexesThinBackend(
         OldPrefix, NewPrefix, options::thinlto_emit_imports_files,
         options::thinlto_linked_objects_file);
+    Conf.ForceThinLTO = true;
   }
 
   Conf.OverrideTriple = options::triple;
   Conf.DefaultTriple = sys::getDefaultTargetTriple();
 
   Conf.DiagHandler = diagnosticHandler;
 
   Conf.PreOptModuleHook = [](size_t Task, Module &M) {
check(Conf.addSaveTemps(output_name + ".",
                             /* UseInputModulePath */ true));
     break;
   }
 
   return llvm::make_unique<LTO>(std::move(Conf), Backend,
                                 ParallelCodeGenParallelismLevel);
 }
 
 /// gold informs us that all symbols have been read. At this point, we use
 /// get_symbols to see if any of our definitions have been overridden by a
 /// native object file. Then, perform optimization and codegen.
 static ld_plugin_status allSymbolsReadHook() {
   if (Modules.empty())
     return LDPS_OK;
 
   if (unsigned NumOpts = options::extra.size())
     cl::ParseCommandLineOptions(NumOpts, &options::extra[0]);
 
   std::unique_ptr<LTO> Lto = createLTO();
 
   for (claimed_file &F : Modules) {
     PluginInputFile InputFile(F.handle);
     const void *View = getSymbolsAndView(F);
-    if (!View)
+    if (!View) {
+      check(Lto->addNotLinkedModule(F.name),
+            std::string("Failed to link module ") + F.name);
       continue;
+    }
     addModule(*Lto, F, View);
   }
 
   SmallString<128> Filename;
   // Note that getOutputFileName will append a unique ID for each task
   if (!options::obj_path.empty())
     Filename = options::obj_path;
   else if (options::TheOutputType == options::OT_SAVE_TEMPS)

tools/llvm-lto2/llvm-lto2.cpp

static cl::list<std::string> InputFilenames(cl::Positional, cl::OneOrMore,
                                             cl::desc("<input bitcode files>"));
 
 static cl::opt<std::string> OutputFilename("o", cl::Required,
                                            cl::desc("Output filename"),
                                            cl::value_desc("filename"));
 
 static cl::opt<bool> SaveTemps("save-temps", cl::desc("Save temporary files"));
 
+static cl::opt<bool>
+    ThinLTOIndexOnly("thinlto-index-only",
+                     cl::desc("Emit individual index files and exit"));
+
 static cl::list<std::string> SymbolResolutions(
     "r",
     cl::desc("Specify a symbol resolution: filename,symbolname,resolution\n"
              "where \"resolution\" is a sequence (which may be empty) of the\n"
              "following characters:\n"
              " p - prevailing: the linker has chosen this definition of the\n"
              "     symbol\n"
              " l - local: the definition of this symbol is unpreemptable at\n"
int main(int argc, char **argv) {
   Conf.DiagHandler = [](const DiagnosticInfo &) {
     exit(1);
   };
 
   if (SaveTemps)
     check(Conf.addSaveTemps(OutputFilename + "."),
           "Config::addSaveTemps failed");
 
-  LTO Lto(std::move(Conf));
+  ThinBackend Backend;
+  if (ThinLTOIndexOnly) {
+    // FIXME: Support passing in old/new prefix and linked object file.
+    Backend = createWriteIndexesThinBackend(
+        /* OldPrefix = */ "", /* NewPrefix = */ "",
+        /* ShouldEmitImportsFiles = */ true, /* LinkedObjectsFile = */ "");
+    Conf.ForceThinLTO = true;
+  }
+
+  LTO Lto(std::move(Conf), Backend);
 
   bool HasErrors = false;
   for (std::string F : InputFilenames) {
     std::unique_ptr<MemoryBuffer> MB = check(MemoryBuffer::getFile(F), F);
     std::unique_ptr<InputFile> Input =
         check(InputFile::create(MB->getMemBufferRef()), F);
 
     std::vector<SymbolResolution> Res;