[PATCH] D69760: [Clang][Driver] Don't pun -fuse-ld=lld as -fuse-ld=lld-link with msvc

[Martin Storsjö via Phabricator via cfe-commits]

mstorsjo added a comment.

In D69760#1739044 <https://reviews.llvm.org/D69760#1739044>, @Ericson2314 wrote:

> While I am fine making `-fuse-ld=lld` mean "use that lld driver most appropriate for the clang driver", in principle the clang driver and lld driver choices are orthogonal


In principle, but as ld.lld and lld-link uses different syntaxes that only really are handled correctly if passed through from the gcc and cl drivers respectively, I find it mostly theoretical to want to use them in the opposite combination forms. (Additionally, in practice, people using the cl driver in many cases call (lld-)link directly as it requires very little boilerplate options, contrary to unix style environments where one is supposed to pass in paths to crt2.o and crtbegin.o and the builtins library, etc. So if one wants to use a link style linker it's in most cases easiest to just call it directly instead of using the $CC frontend.)

> and I'd want to expose that with something like `-fuse-ld=ld.lld` to compliment `-fuse-ld=lld-link`.

I don't mind adding these two cases as explicit overrides over the generic logic

> How does that sound? Should we support `-fuse-ld=ld.bfd` and `-fuse-ld=ld64.lld` too?

I don't see where you'd need those? `-fuse-ld=bfd` should pick `ld.bfd` in most cases, right? In which case wouldn't it? The mapping between parameter name to `-fuse-ld` and system linker naming scheme varies a bit between the platforms, and I'd presume the other existing toolchains in clang does this right as it is right now. Or can you clarify and elaborate in which cases you'd want to use them?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69760/new/

https://reviews.llvm.org/D69760