llvm dev - Mar 2018 - [RFC] Making .eh_frame more linker-friendly

I am very interested in reviving this.



Did anyone get any further with these ideas?



@Grimar: Did you do any profiling of the code? Were the slowdowns

you were seeing fundamental (i.e. due to IO) or could a more optimal

implementation reduce the slowdown? Did you do any end to end

timings for compilation + link time?



The same issues arise for all metadata sections:



.eh_frame

.debug_*

.stack_sizes

etc...



In our proprietary linker we've had to implement special handling

for each of these sections, which we'd love to be able to remove or

reduce.



One fundamental problem is overhead. I posted about

this on the gabi list:



https://groups.google.com/d/msg/generic-abi/A-1rbP8hFCA/EDA7Sf3KBwAJ



Take the .stack_sizes section. There is an llvm bug

which suggests that we should produce multiple .stack_size

sections rather than one monolithic .stack_size section:

https://bugs.llvm.org/show_bug.cgi?id=36717.

However, for .stack_sizes the payload is on average 10 bytes

per function. Splitting into multiple sections on elf x86-64 adds

a overhead of 128 bytes per function. An order of magnitude

increase. However, I don't know of any way to avoid this increase

without adding special case code to the linker?



Another thought is that although the gnu linkers are a concern

upstream, ​on our platform (and others where we are fully in control),

we could use this approach for .eh_frame. We would be able to test

and maintain the separate code paths in the backend.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180328/c55c4bbe/attachment.html>

>@Grimar: Did you do any profiling of the code? Were the slowdowns
>you were seeing fundamental (i.e. due to IO) or could a more optimal
>implementation reduce the slowdown? Did you do any end to end
>timings for compilation + link time?

No, as far I remember I did not profile this. All results I had were about
linker
timing for linking clang (posted in this thread).

I think the slowdown is natural. The more input sections we have the slower we
are.
Since LLD is very fast by nature, honestly I do not really believe there is a
huge
chance to significantly boost the observed ~12(?) percents slowdown.
Otherwise, that would probably be done earlier for the common case.


George.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180328/9ff9ab65/attachment.html>

I performed additional benchmarking today and also profiled this.
Previously I tried to link clang. I decided to take something much larger today.
So what I did was: took chromium sources and built 2 sets of objects.
One of them was built with vanilla clang and one with
clang+https://reviews.llvm.org/D40352 patch applied.
As a result, the second set of object contained multiple .eh_frames (for each
text section),
and the first set was just regular set.

Link times after 200 runs were:
1) ~2332ms for the regular set.
2) ~2464ms for "D40352" set.

The difference is about 6%. Does not look too scary as ~10% for clang link time
I had earlier actually.
Note that I did not apply any other patches than D40352. For example, there is a
draft patch for linker
that could use the benefit of objects with multiple .eh_frames to significantly
simplify and even slightly
improve the -gc-sections implementation: https://reviews.llvm.org/D40484.
It could save some time for the case with GC probably.

Also, I tried to profile the difference observed but did not found any visible
bottlenecks.
We seem just become a bit slower everywhere in the linker, I believe this is
caused by natural
reasons: more sections, larger inputs -> slower result.

(I shared both reproduce sets used here:
https://drive.google.com/open?id=15tGIypHOATiodxISRCAbg5iiGTBFXAtc).?



Best regards,
George | Developer | Access Softek, Inc
________________________________
От: George Rimar
Отправлено: 28 марта 2018 г. 18:44
Кому: bd1976 llvm
Копия: Cary Coutant; llvm-dev at lists.llvm.org; nd at arm.com; llvm-dev-request
at lists.llvm.org
Тема: Re: [llvm-dev] [RFC] Making .eh_frame more linker-friendly

>@Grimar: Did you do any profiling of the code? Were the slowdowns
>you were seeing fundamental (i.e. due to IO) or could a more optimal
>implementation reduce the slowdown? Did you do any end to end
>timings for compilation + link time?

No, as far I remember I did not profile this. All results I had were about
linker
timing for linking clang (posted in this thread).

I think the slowdown is natural. The more input sections we have the slower we
are.
Since LLD is very fast by nature, honestly I do not really believe there is a
huge
chance to significantly boost the observed ~12(?) percents slowdown.
Otherwise, that would probably be done earlier for the common case.


George.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180430/e2a2e5ae/attachment-0001.html>