[llvm-dev] Please dogfood LLD

[David Chisnall via llvm-dev]

On 14 Mar 2017, at 18:39, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> LLVM 4.0.0 is out, and I can say that LLD/ELF is now ready for production use at least for x86-64 (and probably for AArch64 and MIPS).

We’re now using it with all three architectures on FreeBSD (though only the n64 ABI for MIPS) and will file bugs.  One QoI issue that’s bitten us a couple of times is that the versions of clang and lld must match for LTO to work.  If they don’t, we don’t get an error message, we simply get programs that segfault on startup.  I’m a bit surprised that reading the bitcode doesn’t return an error that LLD can report and refuse to link.  We’ve seen this error mixing clang 4.0 and lld trunk.

That’s going to make enabling LTO for FreeBSD package builds problematic once we start shipping lld in the base system - anything built with the system compiler will work fine, but anything built with a compiler from ports will silently generate non-working binaries.  Fortunately for LLVM, this includes building a non-working tablegen, so the build fails rather than appearing to succeed and giving non-working binaries.

For dogfooding purposes, it would be very helpful if the LLVM CMake files allowed you to specify the suffix for the system clang and LLD to use in a single place.  Currently, telling it to use lld will pass -fuse-ld=lld, but we typically need to actually pass -fuse-ld=lld40 or -fuse-ld=lld-devel to pick the LLD version that matches the compiler version that we’re using.

David