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

Alexey Karyakin via llvm-commits llvm-commits at lists.llvm.org
Mon May 12 11:49:59 PDT 2025


================
@@ -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
----------------
quic-akaryaki wrote:

> s/CacheFile/CachedFileStream/
> 
> However, can you clarify the sequence of events causing the crash? Looking at PR136121 and CachedFileStream::commit, that function doesn't actually delete anything. I'm also unclear on how deleting the codegen pass manager early prevents use after the call to commit() further below.

Sorry it should have been CacheStream. I tried to describe the crash (briefly) in the associated bug #138194. I don't know why handling the stream is done this way. Closing the stream in the commit function seems the most suspicious to me, But I don't know what depends on the current behavior.

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


More information about the llvm-commits mailing list