[lld] r244934 - Template OutputSection only over Is64Bit.
Rui Ueyama via llvm-commits
llvm-commits at lists.llvm.org
Thu Aug 13 21:19:42 PDT 2015
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.
On Fri, Aug 14, 2015 at 12:31 PM, Sean Silva via llvm-commits <
llvm-commits at lists.llvm.org> wrote:
>
>
> On Thu, Aug 13, 2015 at 8:14 PM, Rafael EspĂndola <
> rafael.espindola at gmail.com> wrote:
>
>> On 13 August 2015 at 23:05, Sean Silva <chisophugis at gmail.com> wrote:
>> >
>> >
>> > On Thu, Aug 13, 2015 at 6:11 PM, Rafael EspĂndola
>> > <rafael.espindola at gmail.com> wrote:
>> >>
>> >> > Feel free to add this sort of thing to a TODO list of interesting
>> things
>> >> > to
>> >> > look at in the future, but please avoid doing
>> >> > microoptimization-without-a-measured-performance-benefit until we
>> have a
>> >> > working linker (and then, hopefully dropping the
>> >> > "without-a-measured-performance-benefit"). Almost every single one of
>> >> > these
>> >> > "NFC" patches are stepping on Michael's toes and holding up real "FC"
>> >> > patches that are what we need to get a working linker.
>> >>
>> >>
>> >> That is the kind of behavior that landed us on the old lld.
>> >
>> >
>> > Reality check: the old LLD was not slow due to lack of
>> microoptimizations.
>>
>> Reality check: I told Michael it would not work when he first told me
>> it was splitting sections and creating constraints to keep the parts
>> together.
>>
>
> 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.
>
> -- Sean Silva
>
>
>>
>> Cheers,
>> Rafael
>>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150814/025f3b40/attachment.html>
More information about the llvm-commits
mailing list