<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Dec 13, 2016 at 1:22 PM, Davide Italiano via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Dec 13, 2016 at 12:22 PM, Rafael Avila de Espindola via<br>
llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> David Chisnall via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> writes:<br>
><br>
>> On 13 Dec 2016, at 19:02, Mehdi Amini via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>>><br>
>>> 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!<br>
>><br>
>> 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.<br>
><br>
> It is pretty horrible actually. Last I measure (March) clang was slower<br>
> than gcc at building llvm+clang. The subject is "llvm and clang are<br>
> getting slower" if you want to search for the details.<br>
><br>
> Another reason for having lld "done" and benchmarked first.<br>
><br>
<br>
</span>I wouldn't use the word "horrible" here.<br>
<br>
I'm not going to express an opinion about lld, and I'm not familiar<br>
enough with clang to judge, but it's pretty clear that the reason LLVM<br>
(in particular the middle-end) is slow is not because it is a library.<br>
It's slow because there are passes using suboptimal algorithms and the<br>
cost of replacing them increases over time for multiple reasons (risk<br>
of introducing miscompiles, not catching cases that people added<br>
because they speed up their microbenchmarks, lack of reviewers, you<br>
name it).<br>
<br>
lld is also in a very particular situation right now because the main<br>
OS where it's used is FreeBSD, which desperately needs a linker to<br>
replace a 10 years-old legacy, so people are willing to change their<br>
linker scripts or user-facing linker features (e.g. options) because<br>
there's no other candy shop in town.<br>
<br>
clang is not in the same situation, because it has to support all C++<br>
(which is by itself far more complicated than anything a linker will<br>
ever support) and llvm has (might want to?) support all kind of crazy<br>
optimizations because it's fundamentally unreasonable to ask an user<br>
to canonicalize/change his code to get better performances that the<br>
optimizer could catch just fine because they're "too complicated".<br>
<br>
I think (but that's just my wild guess) the situation will be<br>
different if lld will ever decide to try to become the system linker<br>
on Linux, where there are already two alternatives so people have much<br>
more flexibility and user may be less keen to change stuffs on their<br>
side to keep the linker simple/fast/clean.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Side note, the amount of complexity in the optimizer is not even<br>
remotely comparable to the one in the linker, so I don't think it's a<br>
fair to talk about performance tracking of the two together.<br>
<br>
That said, I agree that lld received much more attention optimizing<br>
performances than llvm did (although the situation is slowly changing<br>
in the last few months), so llvm has definitely something to learn<br>
from lld on this side (and apparently it is).<br>
<br>
Ciao,<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Davide<br>
<br>
"There are no solved problems; there are only problems that are more<br>
or less solved" -- Henri Poincare<br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div></div>