[PATCH] D36097: Prototype fix for lld DWARF parsing of base address selection entries in range lists

[David Blaikie via llvm-commits]

Thanks for running some numbers - pity there wasn't more of a win. But
props to LLD, I guess :)

On Thu, Aug 3, 2017 at 10:08 PM Rafael Espíndola <rafael.espindola at gmail.com>
wrote:

> At -O0 linking the debug -O0 binaries the results are
>
> base: 9.274785113
> no-base: 9.177534113
>
> so the extra size seems to dominate at -O0
>
> With a regular linking of -O3 binaries the results are
>
> base: 11.765158874
> no-base 11.961078054
>
> But the extra relocations dominate in a regular link.
>
> In any case, the difference is pretty small.
>
> Cheers,
> Rafael
>
>
> On 3 August 2017 at 19:21, Rafael Avila de Espindola
> <rafael.espindola at gmail.com> wrote:
> > I have uploaded 4 build of clangs to
> >
> >  https://s3-us-west-2.amazonaws.com/linker-tests/clang-tests.tar.xz
> >
> > They are 4 cases -O0/-O3 use-dwarf-ranges-base-address-specifier/not
> >
> > I will try benchmarking them in a bit.
> >
> > Cheers,
> > Rafael
> >
> > David Blaikie <dblaikie at gmail.com> writes:
> >
> >> On Thu., 3 Aug. 2017, 5:19 pm Rafael Avila de Espindola via
> llvm-commits <
> >> llvm-commits at lists.llvm.org> wrote:
> >>
> >>> David Blaikie via Phabricator <reviews at reviews.llvm.org> writes:
> >>>
> >>> > (aside: does anyone have an idea of how well LLD scales with the
> number
> >>> of
> >>> > relocations versus the number of bytes of data in a section? I'd
> love to
> >>> know
> >>> > how much this reduction in relocations is worth (like is runtime of
> the
> >>> linker
> >>> > roughly N*relocs + M*raw bytes? Could be interesting to know -
> obviously
> >>> > varying on different configurations (cores, disk speed, etc))
> >>>
> >>> We have a special case for relocations in non alloc sections (like
> debug
> >>> info) that make it pretty fast.
> >>>
> >>> I can try to build clang -O0 -g with and without
> >>> --use-dwarf-ranges-base-address-specifier and compare if you want. Can
> >>> you think of a better test?
> >>>
> >>
> >> An optimised build would be better - more likely to produce
> discontinuous
> >> ranges that use debug_ranges.
> >>
> >> That's where I was seeing this internally - release (O3) builds with
> debug
> >> info (debug info is archives for "just in case" situations)
> >>
> >> It also might be dwarfed (Har Har) by other relocations in a normal -g
> >> build compared to split-dwarf (string relocations especially).
> >>
> >> Depends how far you want to go. I mean I'd be curious about whatever
> data
> >> you can get, for sure.
> >>
> >> If you could measure the size or number of relocations in debug_*
> sections
> >> of whatever you test, that might be good (but I realise it might be too
> >> much work). That way if we know this change removes X relocs and saves Y
> >> time, we have so many more Xs and Ys we can save. (If you do look that
> far,
> >> really most/all of the relocs we /need/ (ie: the lower bound) are those
> in
> >> debug_line))
> >>
> >>
> >>> Cheers,
> >>> Rafael
> >>> _______________________________________________
> >>> llvm-commits mailing list
> >>> llvm-commits at lists.llvm.org
> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
> >>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170804/4bce8454/attachment.html>