<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 18, 2016 at 8:47 PM, Davide Italiano <span dir="ltr"><<a href="mailto:davide@freebsd.org" target="_blank">davide@freebsd.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, Oct 18, 2016 at 12:36 PM, Rui Ueyama via llvm-commits<br>
<<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br>
> On Tue, Oct 18, 2016 at 8:51 AM, George Rimar <<a href="mailto:grimar@accesssoftek.com">grimar@accesssoftek.com</a>><br>
> wrote:<br>
>><br>
>> > This is a list of items that popped in my mind. Not exhaustive but<br>
>> > probably good enough to start discussing what we should do next.<br>
>><br>
>> ><br>
>> > - FreeBSD: what is the status of building the entire FreeBSD system with<br>
>> > LLD? Can it build everything including the kernel?<br>
>> ><br>
>> > - OpenBSD: it is reported that the current LLD doesn't work well on<br>
>> > their operating system.<br>
>> ><br>
>> > - Linux: pick up a distribution and build all packages with LLD to find<br>
>> > out bugs and unimplemented features.<br>
><br>
><br>
> Well, these three items are really the most important items. :)<br>
><br>
>><br>
>> ><br>
>> > - Unimplemented features: at least I wanted to support<br>
>> > --no-ctors-in-init-array.<br>
>> ><br>
>><br>
>> I reviewed gold code and found that difference in our and their<br>
>> implementation is that by default (--ctors-in-init-array)<br>
>> in gold .ctors sections are output in .init_array sections, and .dtors<br>
>> sections are output in .fini_array sections. And they preserve the original<br>
>> names (not renamed to .init_array/.fini_array) when --no-ctors-in-init-array<br>
>> specified. LLD always preserve the original names now. I did not notice<br>
>> other differences, may be I am missing something, what should be done here ?<br>
><br>
><br>
> I don't know. We might have to do nothing. I just noticed that LLD doesn't<br>
> recognize the command line option.<br>
><br>
>><br>
>> > - Safe ICF: is there anything that we can do to support it? I don't like<br>
>> > the way how gold support it (e.g. recognizing ctors/dtors by mangled names,<br>
>> > or detecting >address-taken functions by relocations) because it seems too<br>
>> > tricky to me. We might want to change LLVM to emit hints for linkers.<br>
>> ><br>
>> > - Parallelism: we haven't worked on this area intentionally because we<br>
>> > are pursuing single thread performance at this moment. But because the<br>
>> > linker is now fairly > mature, it might be the time to start thinking about<br>
>> > it. Is there any place we can use multiple threads to speed up? The first<br>
>> > thing that comes to my mind is computing > a build id using multiple<br>
>> > threads.<br>
>> ><br>
>><br>
>> As far I know MD5 and SHA1 can not be parrallized. You sure can split<br>
>> original buffer and compute multiple hashes in parrallel and combine them<br>
>> somehow at the end, but result  of hash(buf1) + hash(buf2) + .... +<br>
>> hashN(bufN) will never be equal to hash(whole bufer). Do you have some<br>
>> specific solution in mind here ?<br>
>><br>
>> > - Ports: how much mature is PowerPC port? We want to support both BE and<br>
>> > LE PowerPCs. It's also interesting to work on an open-source ISA, RISC-V,<br>
>> > because the patches to support the RISC-V architecture are being merged now.<br>
>><br>
>><br>
>> And about --section-ordering-file option mentioned by Davide. Do we want<br>
>> to try it ? if so I probably can work on it.<br>
>> So as far I understand gold implementation this is just a file with<br>
>> wildcarded names that specifies sections order.<br>
><br>
><br>
> I guess it's a lower priority item.<br>
><br>
<br>
</div></div>I am under the impression that the notion of priority largely depends<br>
on somebody's point of view. For my purposes, lld feature-wise is<br>
quite ready (modulo dwo and gdb-index which are getting implemented<br>
anyway), and I have a compelling use-case for the Pettis-Hansen<br>
profiling (at least, something I would like to give it a try), so this<br>
is near the top of my list. You can of course disagree, but saying<br>
it's lower priority is bit of a stretch.<br></blockquote><div><br></div><div>Apologies for my wording. I should have clearly said that that's just my opinion. I'm happy to help you if you decide to work on this item.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks,<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Davide<br>
<br>
"There are no solved problems; there are only problems that are more<br>
or less solved" -- Henri Poincare<br>
</div></div></blockquote></div><br></div></div>