================
@@ -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:
The proposed approach involves defining a new typedef of
`ModuleAnalysisManager` in `PassManager.h`, which could be passed down to a
newly introduced typedef in `ModulePassManager`. For the remainder of this
explanation, I will refer to this new version as `ModulePassManagerWithTM`.
`ModulePassManagerWithTM` would then be used to add all relevant passes in the
BackendUtil.cpp file which are added before and after `BitCodeWriter` Pass.
This change would require incorporating a newly typedef'd Analysis Manager
along with a TargetMachine* TM as arguments to the run functions of all
associated passes even though most of these passes are unrelated to Bitcode
emission.
While the original intent behind this approach was to minimize code changes, it
has become evident that it introduces more complexity than initially
anticipated. Consequently, I believe it is more prudent to revert to the
previously proposed changes.
Accordingly, in the latest commit, I have re-pushed the approach where
TargetOptions are selectively passed only to the necessary passes involved in
Bitcode emission within the pre-LTO pipeline. This has been achieved by
introducing a new data member for TargetOptions.
https://github.com/llvm/llvm-project/pull/143692
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
