search for: d40484

...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 resu...

>@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

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

I performed tests basing on first diff of https://reviews.llvm.org/D40352. (Creates .eh_frame for each .text.*, sets SHF_LINK_ORDER and .sh_link of created .eh_frame section to point to corresponding .text.) With use of GNU ld (GNU Binutils) 2.29.51.20171006 it reports errors when linking sample apps: ~/LLVM/Release/bin/clang++ test.cpp -ffunction-sections -o test.o /usr/local/bin/ld: .eh_frame