================
@@ -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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
