[llvm] [LTO] Fix a crash with thin LTO caching and asm output (PR #138203)

[via llvm-commits]

================
@@ -439,27 +439,33 @@ static void codegen(const Config &Conf, TargetMachine *TM,
   std::unique_ptr<CachedFileStream> &Stream = *StreamOrErr;
   TM->Options.ObjectFilenameForDebug = Stream->ObjectPathName;
 
-  legacy::PassManager CodeGenPasses;
-  TargetLibraryInfoImpl TLII(Mod.getTargetTriple());
-  CodeGenPasses.add(new TargetLibraryInfoWrapperPass(TLII));
-  // No need to make index available if the module is empty.
-  // In theory these passes should not use the index for an empty
-  // module, however, this guards against doing any unnecessary summary-based
-  // analysis in the case of a ThinLTO build where this might be an empty
-  // regular LTO combined module, with a large combined index from ThinLTO.
-  if (!isEmptyModule(Mod))
-    CodeGenPasses.add(
-        createImmutableModuleSummaryIndexWrapperPass(&CombinedIndex));
-  if (Conf.PreCodeGenPassesHook)
-    Conf.PreCodeGenPassesHook(CodeGenPasses);
-  if (TM->addPassesToEmitFile(CodeGenPasses, *Stream->OS,
-                              DwoOut ? &DwoOut->os() : nullptr,
-                              Conf.CGFileType))
-    report_fatal_error("Failed to setup codegen");
-  CodeGenPasses.run(Mod);
-
-  if (DwoOut)
-    DwoOut->keep();
+  // Create the LTO pipeline in its own scope so it gets deleted before
+  // Stream->commit() is called. The commit function of CacheFile deletes
----------------
anjenner wrote:

This kind of ownership issue is unfortunately a common pitfall of C++ - short of rewriting the entire compiler in Rust, there isn't really a general way for object A to protect itself against object B taking a pointer to one of A's sub-objects C that outlasts the lifetime that A expected. However, it's no more fragile than it was before https://github.com/llvm/llvm-project/pull/136121 - if the legacy::PassManager constructor had been moved to before the std::unique_ptr<CachedFileStream> constructor, this problem would have been seen even without https://github.com/llvm/llvm-project/pull/136121 .

As for the other users of CacheStream, I just checked that there was no object constructed after the std::unique_ptr<CachedFileStream> constructor which could outlast the commit() call.

https://github.com/llvm/llvm-project/pull/138203