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

[David Blaikie via llvm-commits]

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/09d601f3/attachment.html>