This patch continues work on speed up --gdb-index LLD option started in D31136.
In this patch I suggest to create separate class GdbIndexBuilderDWARFContent for parsing content required
to build .gdb_index section.
That has next benefits:
- Applying relocations is slow. Building .gdb_index seems requires resolving relocations
only in .debug_info section (for futher collectAddressRanges() call). We dont have to proccess any
other relocations I think. It easy to filter and optimize code separatelly for this case without overcomplicating the logic.
- This patch implements next optimization: only relocatons against symbols in allocatable sections
are handled. That allows to properly collect address ranges and skip all useless relocations in a simple way.
At first I though about adding option to LoadedObjectInfo for that, but it looks very specific feature and easier
to implement it in GdbIndexBuilderDWARFContent instead.
- It also opens road to pass already decompressed sections to parser. Since LLD linker decompresses sections on his side,
it will be convinent to adapt implementation of GdbIndexBuilderDWARFContent to pass decomressed sections instead object::ObjectFile.
That looks not needed for generic parser and would overcomplicate it.
- Creating GdbIndexBuilderDWARFContent allows to move implementation of .gdb_index builder code from LLD to DWARF
parser side, what allows futher reuse.
Patch also implements optimization of relocations processing, like D31136 did.
It is simple now and does not touch main parsers logic.
Number I got when linked llc using LLD with --gdb-index binary are:
Without this patch (average, 5 runs):
25365,272594 task-clock (msec) # 1,312 CPUs utilized ( +- 0,82% ) 16 827 context-switches # 0,663 K/sec ( +- 2,26% ) 893 cpu-migrations # 0,035 K/sec ( +- 8,21% ) 695 748 page-faults # 0,027 M/sec ( +- 0,03% ) 19,330233261 seconds time elapsed
With this patch (average, 5 runs):
15865,250347 task-clock (msec) # 1,554 CPUs utilized ( +- 0,06% ) 15 830 context-switches # 0,998 K/sec ( +- 0,93% ) 963 cpu-migrations # 0,061 K/sec ( +- 4,79% ) 696 143 page-faults # 0,044 M/sec ( +- 0,05% ) 10,209859902 seconds time elapsed ( +- 0,21% )
That makes --gdb-index almost 2x faster for my case !