On 2 Aug 2016, at 05:19, Ed Maste <ema...@freebsd.org> wrote: > >>> 6. Request ports exp-runs and issue a call for testing with 3rd party >>> software. Fix issues found during this process. >> >> Experience suggests this may be the long poll :) > > Indeed, and that's a big part of my motivation for trying to make lld > more readily available as early as possible, even if we're still > waiting on some required features.
I believe that all of the base system clang’s for supported branches support
-fuse-ld=lld (perhaps 10.0 didn’t?), so if we have an lld candidate in ports
then it should be easy for user to test it by doing a pkg ins lld and setting
LDFLAGS. Failing that, the fallback to just replacing /usr/bin/ld with a
symlink to /usr/local/bin/ld.lld would probably work for ports testing.
We’re probably going to want a ‘needs bfd / gold instead of lld’ knob for a
while. We might need to patch the gcc versions in ports to accept
-fuse-ld=lld[1].
I suspect the longer tail for LTO. There is a bunch of low-hanging fruit in
the FreeBSD tree where LTO would likely be a win (I’d expect most of the
statically linked stuff to get smaller, if nothing else).
David
[1] gcc and clang interpret -fuse-ld differently. In clang, -fuse-ld={foo}
means ‘${PATH}/ld.{foo}’ is the linker and you should error out if it doesn’t
exist. gcc instead hard codes bfd and gold as the two valid options and rejects
anything else.
smime.p7s
Description: S/MIME cryptographic signature
