[Bug debug/92442] Compiling Boost.Spirit.X3 code uses exuberant amount of RAM with -gpubnames

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92442

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |jason at gcc dot gnu.org,
                   |                            |mark at gcc dot gnu.org

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
The pubtables cause us to keep otherwise unused type DIEs:

  /* Also set the mark on nodes referenced from the pubname_table.  Enumerators
     are unusual in that they are pubnames that are the children of pubtypes.
     They should only be marked via their parent DW_TAG_enumeration_type die,
     not as roots in themselves.  */
  FOR_EACH_VEC_ELT (*pubname_table, i, pub)
    if (pub->die->die_tag != DW_TAG_enumerator)
      prune_unused_types_mark (pub->die, 1);

and the pubtables itself are not set up to avoid duplicates.  I would guess
for code like Boost Spirit we have gazillions of fancy template instantiations
getting pubnames which blows memory use.  Not sure why -gsplit-dwarf requires
those or if in the modern C++ world the pubnames section are still useful?

size_of_pubnames () at output_pubnames computes 1331806040, "only" 1.3GB
(for generated DWARF), for the data structure in GCC itself we have
19136 entries in pubname_table and 90654 in the pubtype_table which
computes to 3.0GB data.

Overall this hardly sounds useful, esp. if pubname "creation" is done
before unused type pruning.  Not sure why we have add_pubname sprinkled
all over dwarf2out rather than gathering pubnames from a DIE tree walk
at some suitable point (after type pruning, possibly at dwarf2out_early_finish
time before breaking out comdats).