[llvm-dev] Please dogfood LLD

[Sean Silva via llvm-dev]

I didn't mean what I said in a negative way. I think it just very plainly
shows a user's perspective. We already know about the issues in my email
(the libtool hack and that LLD is currently incompatible with GCC LTO). We
know how to fix them too. But we didn't know exactly how problematic they
are when tested in a relatively black-box fashion.

The way that Phoronix tested this is the most brutal possible way (replace
/usr/bin/ld with LLD, and then a simple yes/no "does it work" on various
software packages), but that is the bar that we want to get to, and this is
a piece of information pointing us towards where we want to go.


-- Sean Silva

On Sun, Mar 19, 2017 at 4:53 AM, Renato Golin <renato.golin at linaro.org>
wrote:

> On 19 March 2017 at 01:06, Sean Silva via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > This seems to have caused some bad publicity:
> > https://www.reddit.com/r/programming/comments/601kn9/
> trying_out_llvm_40s_lld_linker/
> > One user even comes away with this impression: "As you can see in the
> link,
> > LLD is unable to link several projects. It's far from production ready."
> > (and I cannot blame them; LLD should "Just Work" with almost all major
> > open-source software packages, and failing 3, including a very common one
> > like libjpeg-turbo which is used by firefox and chromium, doesn't reflect
> > well)
>
> Hi Sean,
>
> You can't avoid bad publicity, even if you do everything right. It
> took Rui almost a year more than it took me to think LLD was good
> enough for wider use, and it still wasn't.
>
> Do you know why? Because it never will.
>
> Toolchain development is a curse as much as it's an bless. You can do
> some amazing software and still be caught with your pants down on
> really simple cases. Different than almost every other software
> technology on the planet (modulo kernel), toolchains have to cope with
> a problem space that is so random, unpredictable and crazy, that it's
> literally impossible to compile every software on the planet. It just
> is.
>
> However, most non-toolchain / non-kernel developers will look at their
> new shiny tool, which claims "production use" and will think: "Oh,
> this *must* work on all the crazy things I've done in the past". Most
> of us know this is non-sense and we shouldn't be deterred by comments
> like this. They're noise, not signal.
>
> The Phoronix article hints at something inspiring: All workloads were
> faster, and some were significantly faster. "Can't compile", as we
> know, can be a simple bug, user error, unsupported GNU extensions,
> lack of tests on that specific platform, etc. They should be fixed,
> yes, but they're not a reflection of your work, let alone "the only"
> reflection.
>
> Maybe one lesson we can learn from this is: don't use the words
> "production ready", but instead "user beta testing". It worked very
> well for Google for the past 10 years and can work for us, too. :)
>
>
> > One user experiencing a segfault appears to have been kind enough to
> send us
> > a bug report: https://bugs.llvm.org/show_bug.cgi?id=32341
>
> Most users are nice. So far, there was only one negative comment...
> Noise, in my view.
>
> The LLD developers are, in my view, doing an amazing job. Please,
> don't be affected by noise.
>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170320/9ffa23bb/attachment.html>