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

Rafael Avila de Espindola via llvm-commits llvm-commits at lists.llvm.org
Thu Aug 3 19:21:15 PDT 2017


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


More information about the llvm-commits mailing list