<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 20, 2017 at 9:38 AM, Rui Ueyama 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"><div dir="ltr"><div>As to the Phoronix benchmark results, I tried linking fftw as an example and got a different result. In my test, ld.bfd, ld.gold and ld.lld are all on par, and that is reasonable because compile time is the dominant factor of building fftw. In the Phoronix tests, LLD was slower than the GNU linkers when linking fftw, and I don't know why. The Phoronix tests measured the entire build time (as opposed to the time that the linker actually consumed), and it seems to me that that is too noisy. (Michael, if you are watching this, you probably want to measure only the time spent by the linker?)</div></div></blockquote><div><br></div><div>Unfortunately it is not very easy to test just the link time in a build (or just the non-link time). I have had to do this in the past and there is no universally applicable solution, so I wouldn't expect Phoronix (which does high-level black-box testing) to do this. That being said, like you mentioned, a small part of the overall (clean / full-rebuild) build time is spent linking for most projects, so I agree that any significant changes in the numbers by switching linkers is suspect (especially between LLD and gold; I've seen BFD be "crazy slow" sometimes).</div><div><br></div><div>The main thing I can think of is that, for example, if the projects' build system detects if the compiler/linker supports LTO (by actually properly testing it, not like stockfish that pretty much hardcodes it, causing the LLD build to fail in this batch of tests), then the LLD links might end up with non-LTO builds and the gold/BFD builds could be doing LTO.</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Regarding the libtool issue, I'm inclined to accept the "GNU" hack. That's not really a bad hack. As Ed explained, that is not going to be fixed easily as the code generated by libtool is copied to so many projects. If we can convince libtool-generated script that we are a GNU compatible linker just by adding "GNU" to somewhere in the --version message, it sounds like a good deal. We can add a string "LLD is a GNU-compatible linker" or "LLD accepts the same command line options as the GNU linker" or something like that to the --version string. I think we need this in reality.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 20, 2017 at 7:17 AM, Rafael Avila de Espindola 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>Michael Johnson <<a href="mailto:mpj@rowley.co.uk" target="_blank">mpj@rowley.co.uk</a>> writes:<br>
<br>
> Hi Rafael,<br>
>> Michael Johnson via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> writes:<br>
>><br>
>>> Hi Rui,<br>
>>><br>
>>> Are there any plans to support the -defsym command line option?<br>
>> It doesn't look that hard, it was just never requested. What project is<br>
>> using it?<br>
> Not sure I understand what the project set is. It's not an uncommon<br>
> feature for a linker in the embedded world.<br>
><br>
> It's the first problem I discovered when trying to use lld rather than<br>
> ld e.g.<br>
><br>
> -defsym=__vfprintf=__vfprintf_<wbr>float_long_long<br>
><br>
> to select a particular implementation of printf.<br>
><br>
> The second problem was failing to parse the .ld script - I can provide<br>
> it if required.<br>
<br>
</span>If you could open bugs for both that would be awesome.<br>
<br>
Thanks,<br>
<div class="m_-7682082767283808048HOEnZb"><div class="m_-7682082767283808048h5">Rafael<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">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></div><br>______________________________<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>
<br></blockquote></div><br></div></div>