[clang] [llvm] Pass TargetMachine from from Clang to `BitcodeWriter`and `ThinLTOBitcodeWriter` pass for thin and fat LTO respectively. (PR #143692)
Garvit Gupta via llvm-commits
llvm-commits at lists.llvm.org
Sun Aug 3 11:42:39 PDT 2025
================
@@ -568,31 +572,44 @@ bool writeThinLTOBitcode(raw_ostream &OS, raw_ostream *ThinLinkOS,
// produced for the full link.
ModuleHash ModHash = {{0}};
WriteBitcodeToFile(M, OS, ShouldPreserveUseListOrder, Index,
- /*GenerateHash=*/true, &ModHash);
+ /*GenerateHash=*/true, &ModHash, TM);
// If a minimized bitcode module was requested for the thin link, only
// the information that is needed by thin link will be written in the
// given OS.
if (ThinLinkOS && Index)
- writeThinLinkBitcodeToFile(M, *ThinLinkOS, *Index, ModHash);
+ writeThinLinkBitcodeToFile(M, *ThinLinkOS, *Index, ModHash, TM);
return false;
}
} // anonymous namespace
PreservedAnalyses
llvm::ThinLTOBitcodeWriterPass::run(Module &M, ModuleAnalysisManager &AM) {
- FunctionAnalysisManager &FAM =
- AM.getResult<FunctionAnalysisManagerModuleProxy>(M).getManager();
-
M.removeDebugIntrinsicDeclarations();
+ FunctionAnalysisManager &FAM =
----------------
quic-garvgupt wrote:
I’ve posted a new patchset using the approach you suggested. However, I was unable to achieve a successful build. The main issue is that this approach requires creating a new AnalysisPassManager, (`ModuleSummaryIndexAnalysisManager` in the latest patchset) that accepts an additional argument of type `const TargetMachine *`. This new pass manager is then passed to the run functions of the callers of `ModuleSummaryIndexAnalysisPass`, namely `BitcodeWriterPass` and `ThinLTOBitCodeWriter`.
Unfortunately, the Pass Manager infrastructure defines the template for AnalysisManager to accept only the `IRUnit` as an argument, and not any additional parameters. Because of this, I’m encountering the following error:
`PassManagerInternal.h:91:25: error: non-c
onst lvalue reference to type 'AnalysisManager<[...], const llvm::TargetMachine *>' cannot bind to a value of
unrelated type 'AnalysisManager<[...], (no argument)>`
Please let me know if I’m missing something in my implementation here or if this is expected.
Also, the new approach was proposed to avoid modifying the call sites of ModuleSummaryIndexAnalysisPass. However, since it is only invoked from two locations, I believe it’s reasonable to proceed with the previous approach instead. I’d appreciate your thoughts on this.
Apologies for the delayed response.
https://github.com/llvm/llvm-project/pull/143692
More information about the llvm-commits
mailing list