Feature: Integrate LLD, the LLVM cross-linker

[kinke]

My tests some weeks ago with LLD 3.9 on Win64 have shown that it really works out-of-the-box as drop-in replacement (lld-link.exe for DLLs and executables, llvm-lib.exe for static libraries) for Microsoft's tools, reading the same environment variables etc. All tests passed except for our CDB debugging tests, as debuginfos on Windows (.pdb) aren't implemented yet, that's the only drawback.

While LLD is supposed to be compact & fast and naturally allows for LLVM goodness like LTO, I see the primary advantage in getting rid of LDC's dependency on a target linker and gaining the ability to directly cross-compile and -link. All you need are the target system libs + target druntime/Phobos, and you'll be able to generate shared libs and executables for about any target supported by LLVM. No need for an external cross-linker or linking natively / in an emulator.

By linking the LLD library into LDC directly, we should be able to forward pretty much unchanged command lines to one of the 3 drivers, depending on targeted platform, instead of invoking the external linker (which should still be possible via cmdline option).
Without relying on an external LLD executable, detecting the MSVC++ installation and setting up the environment variables on Windows will have to be moved from the currently used batch files to LDC itself.

[JohanEngelen]

This'd be really great.

How do you propose to expose this to the user? Add a -link-with-lld/-internal-linker cmdline flag?

[kinke]

In the long run and assuming LLD will turn out nearly perfectly compatible (in terms of command-line semantics, incl. .pdb generation) to the 3 system linkers, I'd prefer it to be the default setting and letting users specify an external linker to be invoked via -linker= and archiver/librarian via -archiver= (or so).
In the meantime, exposing it opt-in via something like your proposals sounds good.

[kinke]

@JohanEngelen: Wrt. your question in the forum, I assume(d) LLD features LTO directly, not requiring any plugin.

I simply cloned the lld repo into llvm/tools, rebuilt LLVM, hacked LDC to make use of the LLVM tools (link.exe => lld-link.exe, lib.exe => llvm-lib.exe) and ran our test-suite. :)

Edit: Oh wait, there's a 27M LTO.dll file in the LLVM installation directory. So apparently built & installed by default on Windows.
Edit2: I (willingly) included LLD (and unknowingly LTO.dll) in the prebuilt LLVM 3.9.1 for AppVeyor. I guess that basically makes LTO on Windows testable via AppVeyor.

[JohanEngelen]

Wrt. your question in the forum, I assume LLD features LTO directly, not requiring any plugin.

Yeah :)

Edit: see http://releases.llvm.org/3.9.0/tools/lld/docs/ReleaseNotes.html#link-time-optimization

[kinke]

@klickverbot etc.: What's the rationale for using gcc as linker driver on non-Windows instead of ld directly? As LLD is a drop-in replacement for ld, integrating it would be simpler if we invoked the system ld.

[dnadlinger]

What's the rationale for using gcc as linker driver on non-Windows

@kinke: D programs implicitly link against the C runtime. Using gcc as the linker driver makes sure the C runtime (whatever it might be for the system/target in question) is linked automatically.

[dnadlinger]

(Other languages – e.g. Rust, … – tend to do the same.)

[kinke]

I thought locating the MS tools and setting up the MSVC environment variables on Windows would be a pain. Comparing this with how it's done on Linux (on Ubuntu, gcc -> collect2 -> ld, with a huge and extremely ugly command line viewable via gcc -v -o foo foo.obj), it's actually a bliss. Integrating LLD for Windows targets would now take a couple of minutes (mainly figuring out the needed LLD libs), but that's exactly the platform which still needs some work (.pdb). So I'll let this rest for the time being.

[WebDrake]

@kinke: D programs implicitly link against the C runtime. Using gcc as the linker driver makes sure the C runtime (whatever it might be for the system/target in question) is linked automatically.

But that nevertheless produces quite a strong constraint on usage options. Could it make sense to instead allow the user to specify a choice of linker (with gcc being the default) together with an option to specify the location of the C runtime to use, for the cases where the chosen linker doesn't automatically know?

Vested (though speculative) interest: it might be a good idea for the snap-packaged LDC to insist on linking against the C runtime from the core snap, instead of the host system.

[dnadlinger]

Could it make sense to instead allow the user to specify a choice of linker

Exists today in the form of the CC environment variable and other hidden options.

together with an option to specify the location of the C runtime to use, for the cases where the chosen linker doesn't automatically know?

There doesn't need to be an option for that, just add it to the linker flags, or point LDC to a wrapper ("driver", in case you feel fancy) script for the linker executable that adds the appropriate option.

[WebDrake]

Exists today in the form of the CC environment variable and other hidden options.

So LDC actually uses the CC environment variable as its linker driver? Perhaps it would be as well to stop so explicitly talking about the use of gcc as the linker? Or is there a stronger assumption about what CC is in practice?

[dnadlinger]

Perhaps it would be as well to stop so explicitly talking about the use of gcc as the linker?

Yes – well, as long as it is able to resolve it to an actual executable path. Apart from Windows/MSVC, though, LDC assumes a GCC-compatible command line syntax for the linker, so talking about gcc is probably quite warranted.

[WebDrake]

LDC assumes a GCC-compatible command line syntax for the linker, so talking about gcc is probably quite warranted.

That's what I suspected. But could one invoke LDC specifying CC=ld (plus appropriate linker flags) and expect it to succesfully invoke ld as the linker?

[kinke]

Nope, that's exactly the problem, see https://github.com/ldc-developers/ldc/blob/master/driver/linker.cpp#L289. The -shared flag for instance has totally different semantics for gcc and ld.

[dnadlinger]

But could one invoke LDC specifying CC=ld (plus appropriate linker flags) and expect it to succesfully invoke ld as the linker?

Unfortunately no, as it will translate -L into -Xlinker and so on, which ld won't understand. If you wanted to submit a PR that adds a flag to specify the linker type, though, I would certainly merge it.