[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]

================
@@ -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