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