[llvm-dev] LLD status update and performance chart

[Davide Italiano via llvm-dev]

On Tue, Dec 13, 2016 at 1:54 PM, Rui Ueyama <ruiu at google.com> wrote:
> 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.
>

It's the other way around. lld more than once resulted in change in
FreeBSD, see for example Kostik's comment in
https://reviews.freebsd.org/D8610#178738


> 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.
>

lld is reasonable for my purposes as it is. That's why I deliberately
avoided to comment on lld as a library.

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare