This is an archive of the discontinued LLVM Phabricator instance.

[ELF] - Do not apply relocations to .debug_ranges when building -gdb-index
AbandonedPublic

Authored by grimar on Jul 5 2017, 4:17 AM.

Details

Summary

Looks we do not really need to apply relocations to .debug_ranges section
when building .gdb_index.

What we need is to scan relocations and take target section indices use addends
as begin/end addresses.
That allows to skip actual relocations computations and speedups building .gdb_index.

When linking llc binary with -gdb-index numbers I got (from 25 runs) were:

  • Without this patch: 5,724493319 seconds time elapsed ( +- 0,13% )
  • With this path: 5,352222105 seconds time elapsed ( +- 0,10% )

It is about 6.5% speedup.

Diff Detail

Event Timeline

grimar created this revision.Jul 5 2017, 4:17 AM
grimar updated this revision to Diff 105246.Jul 5 2017, 4:22 AM
  • Removed unrelative change.
dblaikie added inline comments.Jul 5 2017, 10:06 AM
ELF/SyntheticSections.cpp
1821–1822

Any particular reason this would only be done for ranges sections and not for other sections?

1851

This function always returns true, so may be better off having void return instead. The return value doesn't seem to be communicating anything.

grimar added inline comments.Jul 6 2017, 5:16 AM
ELF/SyntheticSections.cpp
1821–1822

I tried to focus on feature itself and keep patch as short as possible for initial review.
I think that can be done for all sections required for building .gdb_index (though I did not check by myself yet).
At least I do not know any reason why it should not work atm.

ruiu edited edge metadata.Jul 11 2017, 4:25 PM

Looks like this patch does a tricky thing only to gain 6.5% speedup. If we are behind gold by 6.5%, this might be worth adding, but the performance gap is much more than that, no? If so, it seems a premature optimization to me.

In D35005#805855, @ruiu wrote:

Looks like this patch does a tricky thing only to gain 6.5% speedup. If we are behind gold by 6.5%, this might be worth adding, but the performance gap is much more than that, no? If so, it seems a premature optimization to me.

This patch was placed on hold recently.
Rafael mentioned (D35004 + D35236 threads) a different patch for parsers he working on, which perfomance results sounds much better.

grimar abandoned this revision.Jul 17 2017, 8:29 AM

I assume D35386 will be landed instead.