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

[George Rimar via llvm-dev]

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>