[PATCH] D40697: Cache modulo values for the .gnu.hash section.

[Rafael Avila de Espindola via llvm-commits]

Lnt has some logic for deciding if the change is significant or not.

Looks like only clang has enough symbols (because of export dynamic) for the patch to make a difference.

I will attach a table with all the numbers.

Cheers,
Rafael

On December 1, 2017 3:34:29 PM PST, Rui Ueyama <ruiu at google.com> wrote:
>Does the attached image show the benchmark results? I wonder what are
>numbers in the other rows than clang and clang-fsds.
>
>On Fri, Dec 1, 2017 at 3:31 PM, Rafael Espíndola
><rafael.espindola at gmail.com
>> wrote:
>
>> >> OK, that makes it more likely that this is useful, but I still
>think
>> >> we should fully benchmark every single optimization.
>> >
>> >
>> > It depends. Your test cases do not cover all possible use cases,
>and
>> since
>> > this is an optimization for that particular code path, it actually
>makes
>> > more sense to only measure the speed of that particular path. The
>> benchmark
>> > numbers would be more noisy if you measure the entire execution
>time.
>>
>> If the results don't show up in a full run then it is probably not
>> something that is worth optimizing for.
>>
>> > It still make some sense to run some benchmarks just in case,
>because
>> some
>> > seemingly unrelated change could results in a surprising
>performance
>> > degradation, but for that purpose, running one or two benchmarks
>should
>> > enough.
>>
>> I still disagree. We had bad performance regressions from testing
>just
>> clang in the part and running all the benchmarks is pretty easy now
>> that the script is in lld.
>>
>> In any case, the results look good, so LGTM.
>>
>>
>> Cheers,
>> Rafael
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20171201/66295dd3/attachment.html>