[llvm-dev] LLD status update and performance chart

[Rui Ueyama via llvm-dev]

On Tue, Dec 13, 2016 at 1:22 PM, Davide Italiano via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Tue, Dec 13, 2016 at 12:22 PM, Rafael Avila de Espindola via
> llvm-dev <llvm-dev at lists.llvm.org> wrote:
> > David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> writes:
> >
> >> On 13 Dec 2016, at 19:02, Mehdi Amini via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >>>
> >>> I’m totally willing to believe you that it is not possible to write
> the fastest ELF linker on earth (or in the universe) with a library based
> and reusable components approach. But clang is not the fastest C/C++
> compiler available, and LLVM is not the fastest compiler framework either!
> >>
> >> I’m not how it compares now, but at least when I started contributing
> and for a year or two after the speed of clang (especially at O0, for fast
> compile-test-debug cycles) was one of its big selling points.
> >
> > It is pretty horrible actually. Last I measure (March) clang was slower
> > than gcc at building llvm+clang. The subject is "llvm and clang are
> > getting slower" if you want to search for the details.
> >
> > Another reason for having lld "done" and benchmarked first.
> >
>
> I wouldn't use the word "horrible" here.
>
> I'm not going to express an opinion about lld, and I'm not familiar
> enough with clang to judge, but it's pretty clear that the reason LLVM
> (in particular the middle-end) is slow is not because it is a library.
> It's slow because there are passes using suboptimal algorithms and the
> cost of replacing them increases over time for multiple reasons (risk
> of introducing miscompiles, not catching cases that people added
> because they speed up their microbenchmarks, lack of reviewers, you
> name it).
>
> lld is also in a very particular situation right now because the main
> OS where it's used is FreeBSD, which desperately needs a linker to
> replace a 10 years-old legacy, so people are willing to change their
> linker scripts or user-facing linker features (e.g. options) because
> there's no other candy shop in town.
>
> clang is not in the same situation, because it has to support all C++
> (which is by itself far more complicated than anything a linker will
> ever support) and llvm has (might want to?) support all kind of crazy
> optimizations because it's fundamentally unreasonable to ask an user
> to canonicalize/change his code to get better performances that the
> optimizer could catch just fine because they're "too complicated".
>
> I think (but that's just my wild guess) the situation will be
> different if lld will ever decide to try to become the system linker
> on Linux, where there are already two alternatives so people have much
> more flexibility and user may be less keen to change stuffs on their
> side to keep the linker simple/fast/clean.
>

I don't know if FreeBSD support affected the LLD architecture. FreeBSD
affected the priority of the to-do items for sure, but the linker
architecture was set much before we started experimenting it on FreeBSD.

I'd object the binary-ish thinking that we had two exclusive choices, speed
or modularity (whatever it means in the linker's context). It's not what I
have in my mind. LLD is usable as a library already, you can embed it to
your product, and I believe that satisfies many use cases. That's modular
(you can use a linker as a module) and very fast. What do you want more
than that? If you want more features for different use cases, please bring
up.

Side note, the amount of complexity in the optimizer is not even
> remotely comparable to the one in the linker, so I don't think it's a
> fair to talk about performance tracking of the two together.
>
> That said, I agree that lld received much more attention optimizing
> performances than llvm did (although the situation is slowly changing
> in the last few months), so llvm has definitely something to learn
> from lld on this side (and apparently it is).
>
> Ciao,
>
> --
> Davide
>
> "There are no solved problems; there are only problems that are more
> or less solved" -- Henri Poincare
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161213/9f6c61f7/attachment.html>