dwz dwarf-5 optimization

dwz dwarf-5 optimization

[Tom de Vries]

Hi,

on IRC you mentioned you wanted to implement an optimization in dwz
supporting dwarf-5, but I don't recall what the optimization was.  For
my understanding, could you shortly describe it?

Thanks,
- Tom

Re: dwz dwarf-5 optimization

[Jakub Jelinek]

On Wed, Feb 10, 2021 at 11:57:45AM +0100, Tom de Vries wrote:
> on IRC you mentioned you wanted to implement an optimization in dwz
> supporting dwarf-5, but I don't recall what the optimization was.  For
> my understanding, could you shortly describe it?

Basically, try to use DW_FORM_implicit_const whenever beneficial.
The compiler doesn't create DW_FORM_implicit_const very much,
optimize_implicit_const in GCC only sees a single TU at a time, while dwz
can see the whole binary, shared library or the supplemental object.
Also, GCC optimize_implicit_const works only on if all the attributes are
the same use DW_FORM_implicit_const, rather than say if 50% of them have
the same const, 25% another one and 25% another one, then it might be
beneficial to create 3 abbrevs.

So, somewhere in compute_abbrevs after build_abbrevs go through the abbrevs
sorted by usage counts from highest usage count to lowest and for each
abbrev that has candidate attributes (constant form other than
DW_FORM_implicit_const with small enough sizes that it could be turned into
DW_FORM_implicit_const) go through all DIEs referencing that abbrev and see
how many have the same value for one (or more of those attributes), and
in that case compare the costs - keeping it as is, or creating a new
abbreviation (which implies the size of the new abbreviation added to
.debug_abbrev, plus perhaps with >= abbrevs also using larger abbrev numbers
vs. getting rid of the attribute in the DIEs) and when beneficial, add new
abbreviation with DW_FORM_implicit_const for that (or multiple attributes)
and repeat.  Not sure if a greedy algorithm would be good enough for that,
and what data structures to use for that, possibly gather just once pointers
to all DIEs into array and qsort that so that we have DIEs for the same
abbrev next to each other and when splitting reorder elts of that array for
the particular DIE.

compute_abbrevs right now works by doing everything intra-CU only and only
afterwards perform some limited attempts to share abbrevs between multiple
CUs.  That perhaps might not play well with that optimization, because it
increases number of abbreviations and so there could be less sharing.

So, what we might also consider is doing test compute_abbrevs twice,
once in the current mode, where each TU creates its own abbrevs and we then
merge them when possible, and then in another mode, which would do
build_abbrevs_for_die for all DIEs in all TUs at once (maybe better just all DIEs
with the same dwarf version at once), and compare which of
these brings bigger savings.  Doing all DIEs in all TUs at once might result
in larger abbrev numbers in .debug_info, but might decrease the overall size
of .debug_abbrev a lot.

Unrelated, if we decide to support -fdebug-types, I'd be for only supporting
it for -gdwarf-5 when it is in .debug_info (or at least initially), and try
to undo the size damage by turning all the DW_UT_type units into
DW_UT_partial and replacing the long DW_FORM_ref_sig8 references with normal
refs.

	Jakub