<div dir="ltr">I think I feel the same way as Sean's. This change does not seem particularly good or bad, but this is indeed a micro-optimization which might be a premature optimization at this development stage. And the new code is a little bit harder than before (although very little) because previously ELFT was everywhere if the ELF type matters, and that was pretty straightforward. Now we have two cases -- full ELFT is available or only 64-bit or not is available.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 14, 2015 at 12:31 PM, Sean Silva via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@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"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Thu, Aug 13, 2015 at 8:14 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 13 August 2015 at 23:05, Sean Silva <<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>> wrote:<br>
><br>
><br>
> On Thu, Aug 13, 2015 at 6:11 PM, Rafael Espíndola<br>
> <<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>> wrote:<br>
>><br>
>> > Feel free to add this sort of thing to a TODO list of interesting things<br>
>> > to<br>
>> > look at in the future, but please avoid doing<br>
>> > microoptimization-without-a-measured-performance-benefit until we have a<br>
>> > working linker (and then, hopefully dropping the<br>
>> > "without-a-measured-performance-benefit"). Almost every single one of<br>
>> > these<br>
>> > "NFC" patches are stepping on Michael's toes and holding up real "FC"<br>
>> > patches that are what we need to get a working linker.<br>
>><br>
>><br>
>> That is the kind of behavior that landed us on the old lld.<br>
><br>
><br>
> Reality check: the old LLD was not slow due to lack of microoptimizations.<br>
<br>
</span>Reality check: I told Michael it would not work when he first told me<br>
it was splitting sections and creating constraints to keep the parts<br>
together.<br></blockquote><div><br></div></span><div>How is that relevant? I don't recall Michael ever particularly championing for that design anyway. Anyway, at this point basing elf2 on Rui's design has already dealt with all the macro-scale performance issues. The "performance from the start" has already mostly been done by virtue of that. All we really need is to add the corresponding ELF functionality. We shouldn't need to worry too much about performance until we can actually profile.</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">
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div></div>
<br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div>