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

[Rafael Espíndola via llvm-commits]

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