[clang] [lld] [llvm] Integrated Distributed ThinLTO (DTLTO): Initial support (PR #126654)

[Fangrui Song via cfe-commits]

================
@@ -535,6 +535,21 @@ void tools::gnutools::Linker::ConstructJob(Compilation &C, const JobAction &JA,
                   D.getLTOMode() == LTOK_Thin);
   }
 
+  // Forward the DTLTO options to the linker. We add these unconditionally,
+  // rather than in addLTOOptions() as it is the linker that decides whether to
+  // do LTO or not dependent upon whether there are any bitcode input files in
+  // the link.
+  if (Arg *A = Args.getLastArg(options::OPT_fthinlto_distributor_EQ)) {
+    CmdArgs.push_back(
+        Args.MakeArgString("--thinlto-distributor=" + Twine(A->getValue())));
+    CmdArgs.push_back(
+        Args.MakeArgString("--thinlto-remote-opt-tool=" +
+                           Twine(ToolChain.getDriver().getClangProgramPath())));
+
+    for (auto A : Args.getAllArgValues(options::OPT_Xthinlto_distributor_EQ))
+      CmdArgs.push_back(Args.MakeArgString("-mllvm=-thinlto-distributor-arg=" + A));
----------------
MaskRay wrote:

I am curious why we don't use a regular linker option. In lld, you could use `getStrings` to read a list option, e.g.

```
ctx.arg.passPlugins = args::getStrings(args, OPT_load_pass_plugins)
```

However, introducing a new linker option requires changes to all lld ports and llvm-lto. Therefore, perhaps make `--thinlto-remote-opt-tool` a cl::opt tool as well?

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