[llvm-dev] LLD status update and performance chart

[Davide Italiano via llvm-dev]

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.

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