[PATCH] D25234: [LLD][ARM] Garbage collection support for .ARM.exidx sections

[Peter Smith via llvm-commits]

Thank you very much for running the benchmarks, I've set myself up so
that I can least use llvm/clang tools for benchmarks in the future.

I'm hoping to get https://reviews.llvm.org/D25127 (.ARM.exidx support
for executables/shared libraries) reviewed first before committing the
GC changes as that is needed for exceptions to reliably work. I can
commit this one beforehand if preferred though.

On 7 October 2016 at 13:54, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> The results I got:
>
> firefox
>   master 6.314747351
>   patch  6.323219627 1.00134166508x slower
> chromium
>   master 4.258709738
>   patch  4.27246126 1.00322903481x slower
> chromium fast
>   master 1.809771242
>   patch  1.8110003 1.0006791234x slower
> the gold plugin
>   master 0.323923114
>   patch  0.325110017 1.00366415038x slower
> clang
>   master 0.542506842
>   patch  0.54578911 1.00605018729x slower
> llvm-as
>   master 0.031965143
>   patch  0.031986982 1.00068321296x slower
> the gold plugin fsds
>   master 0.351388506
>   patch  0.352764988 1.0039172653x slower
> clang fsds
>   master 0.620528058
>   patch  0.622517783 1.00320650287x slower
> llvm-as fsds
>   master 0.029737966
>   patch  0.029761825 1.00080230773x slower
> scylla
>   master 2.776627085
>   patch  2.816265215 1.01427564048x slower
>
> So it seems a pretty small slowdown. I would say go for it. There will
> be a few passes of profile/optimize in the future, but getting ARM
> supported first should make design decisions easier to make.
>
> Cheers,
> Rafael
>
>
>
>
> On 7 October 2016 at 08:15, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>> No worries. This LGTM. It is quite a bit cleaner. I wish other arches
>> used something like that instead of .eh_frame.
>>
>> I will benchmark and open a bug if we need to try to recover the performance.
>>
>> Cheers,
>> Rafael
>>
>>
>>
>> On 7 October 2016 at 05:27, Peter Smith <peter.smith at linaro.org> wrote:
>>> peter.smith added a comment.
>>>
>>> The initial patch did start that way. The SHF_LINK_ORDER sections that become live may make other sections that have further SHF_LINK_ORDER dependencies live so it ends up needing to converge. The move to adding the reverse dependency came from an earlier review comment.
>>>
>>> I'll try and see what impact the extra field in InputSection has in terms of performance. I've not got a setup for benchmarking right now but I'll take a look at setting one up.
>>>
>>> Another possibility is to store the reverse dependency in a map so that only the ARM Target pays the performance cost.
>>>
>>>
>>> https://reviews.llvm.org/D25234
>>>
>>>
>>>