[Bug lto/86654] [9 Regression] ICE in gen_member_die, at dwarf2out.c:24933

rguenther at suse dot de gcc-bugzilla@gcc.gnu.org
Tue Jul 24 15:18:00 GMT 2018


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

--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 24 Jul 2018, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86654
> 
> --- Comment #9 from Martin Liška <marxin at gcc dot gnu.org> ---
> (In reply to rguenther@suse.de from comment #8)
> > On Tue, 24 Jul 2018, marxin at gcc dot gnu.org wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86654
> > > 
> > > --- Comment #7 from Martin Liška <marxin at gcc dot gnu.org> ---
> > > With the dwarf2out.c file patches, now the library builds. But it took my ~30
> > > minutes of linking, seeing perf top:
> > > 
> > >     36.96%  lto1           [.] lookup_external_ref
> > >     18.60%  lto1           [.] hash_table<external_ref_hasher,
> > > xcallocator>::find_empty_slot_for_expand
> > >      4.68%  as             [.] hash_lookup.isra.0
> > >      1.92%  as             [.] resolve_symbol_value
> > >      0.74%  lto1           [.] mark_used_flags
> > >      0.72%  as             [.] relax_segment
> > 
> > So you applied the first patch as well?  That was for debugging.  And
> > it didn't fire?  That's very good ;)
> 
> No, no, only the one-liner in dwarwf2out.c.

Ok, so optimize_external_refs is somehow expensive.  Note it
wont' actually do anything but it still builds a map of
all external debug refs ...

I guess I should try to optimize this.  Can you open a PR for this?

> > 
> > > and debug info of the shared library looks huge:
> > > 
> > > bloaty ./obj-x86_64-pc-linux-gnu/toolkit/library/libxul.so
> > >      VM SIZE                       FILE SIZE
> > >  --------------                 --------------
> > >    0.0%       0 .debug_info       937Mi  52.7%
> > >    0.0%       0 .debug_loc        339Mi  19.1%
> > >    0.0%       0 .debug_str        159Mi   9.0%
> > >    0.0%       0 .debug_ranges     110Mi   6.2%
> > >    0.0%       0 .debug_line      69.0Mi   3.9%
> > >   68.3%  65.3Mi .text            65.3Mi   3.7%
> > >    0.0%       0 .strtab          33.1Mi   1.9%
> > >    0.0%       0 .symtab          24.4Mi   1.4%
> > >    0.0%       0 .debug_abbrev    9.99Mi   0.6%
> > >    8.3%  7.91Mi .rela.dyn        7.91Mi   0.4%
> > >    8.0%  7.67Mi .rodata          7.67Mi   0.4%
> > >    6.2%  5.89Mi .eh_frame        5.89Mi   0.3%
> > >    4.1%  3.90Mi .data.rel.ro     3.90Mi   0.2%
> > >    1.7%  1.59Mi .dynstr          1.59Mi   0.1%
> > >    1.4%  1.35Mi .eh_frame_hdr    1.35Mi   0.1%
> > >    1.0%   990Ki [Other]          1003Ki   0.1%
> > >    0.6%   616Ki .bss                  0   0.0%
> > >    0.4%   398Ki .dynsym           398Ki   0.0%
> > >    0.0%       0 .debug_pubtypes   349Ki   0.0%
> > >    0.0%       0 .debug_pubnames   285Ki   0.0%
> > >    0.0%      23 [None]                0   0.0%
> > >  100.0%  95.6Mi TOTAL            1.74Gi 100.0%
> > 
> > Not so bad I think.  How's its size without LTO?
> 
> Oh, you were right, it's really improvement:
> 
> bloaty ./obj-x86_64-pc-linux-gnu/toolkit/library/libxul.so
>      VM SIZE                       FILE SIZE
>  --------------                 --------------
>    0.0%       0 .debug_info       979Mi  48.6%
>    0.0%       0 .debug_loc        458Mi  22.8%
>    0.0%       0 .debug_str        158Mi   7.9%
>    0.0%       0 .debug_ranges     132Mi   6.6%
>    0.0%       0 .debug_line       112Mi   5.6%
>   67.6%  74.6Mi .text            74.6Mi   3.7%
>    0.0%       0 .strtab          37.8Mi   1.9%
>    0.0%       0 .symtab          14.0Mi   0.7%
>    0.0%       0 .debug_abbrev    11.4Mi   0.6%
>    7.9%  8.74Mi .eh_frame        8.74Mi   0.4%
>    7.7%  8.49Mi .rodata          8.49Mi   0.4%
>    7.7%  8.47Mi .rela.dyn        8.47Mi   0.4%
>    3.8%  4.20Mi .data.rel.ro     4.20Mi   0.2%
>    1.9%  2.05Mi .eh_frame_hdr    2.05Mi   0.1%
>    1.5%  1.65Mi .dynstr          1.65Mi   0.1%
>    0.9%  1.04Mi [Other]          1.32Mi   0.1%
>    0.0%       0 .debug_aranges   1.29Mi   0.1%
>    0.6%   650Ki .bss                  0   0.0%
>    0.4%   413Ki .dynsym           413Ki   0.0%
>    0.0%       0 .debug_pubtypes   349Ki   0.0%
>    0.0%      15 [None]                0   0.0%
>  100.0%   110Mi TOTAL            1.97Gi 100.0%
> 
> diff:
> 
> ./obj-x86_64-pc-linux-gnu2/toolkit/library/libxul.so --
> ./obj-x86_64-pc-linux-gnu/toolkit/library/libxul.so
>      VM SIZE                      FILE SIZE
>  ++++++++++++++ GROWING        ++++++++++++++
>   [ = ]       0 .symtab        +10.3Mi   +74%
>   [ = ]       0 .debug_str      +500Ki  +0.3%
>   +1.0%     +16 .gnu.version_r     +16  +1.0%
>    +53%      +8 [None]               0  [ = ]
> 
>  -------------- SHRINKING      --------------
>   [ = ]       0 .debug_loc      -119Mi -26.0%
>   [ = ]       0 .debug_line    -43.1Mi -38.4%
>   [ = ]       0 .debug_info    -42.1Mi  -4.3%
>   [ = ]       0 .debug_ranges  -22.8Mi -17.2%
>  -12.4% -9.24Mi .text          -9.24Mi -12.4%
>   [ = ]       0 .strtab        -4.73Mi -12.5%
>  -32.7% -2.86Mi .eh_frame      -2.86Mi -32.7%
>   [ = ]       0 .debug_abbrev  -1.46Mi -12.8%
>   [ = ]       0 .debug_aranges -1.28Mi -99.7%
>   -9.6%  -830Ki .rodata         -830Ki  -9.6%
>  -34.1%  -716Ki .eh_frame_hdr   -716Ki -34.1%
>   -6.7%  -578Ki .rela.dyn       -578Ki  -6.7%
>   -7.1%  -304Ki .data.rel.ro    -304Ki  -7.1%
>   -3.6% -61.3Ki .dynstr        -61.3Ki  -3.6%
>   -5.3% -34.6Ki .bss                 0  [ = ]
>  -13.4% -32.9Ki .data          -32.9Ki -13.4%
>   -3.7% -15.4Ki .dynsym        -15.4Ki  -3.7%
>   -5.2% -13.4Ki .rela.plt      -13.4Ki  -5.2%
>   -3.8% -11.3Ki [Other]        -11.8Ki  -3.9%
>   -5.2% -8.92Ki .plt           -8.92Ki  -5.2%
>   -5.2% -4.46Ki .got.plt       -4.46Ki  -5.2%
> 
>  -+-+-+-+-+-+-+ MIXED          +-+-+-+-+-+-+-
>  -68.2%    -161 [Unmapped]        +531   +21%
> 
>  -13.3% -14.7Mi TOTAL           -238Mi -11.8%

Heh, any "improvement" here is of course a possible loss
in debug info precision...

> >    0.0%       0 .debug_info     67.1Mi  52.8%
> >   58.2%  22.1Mi .text           22.1Mi  17.4%
> > 
> > but yes, PR83941 could be a reason for some bloat.  You could try
> > "counting" the number of DIEs that just contain a single 
> > DW_AT_abstract_origin attribute and no children.
> 
> Can you please prepare patch for that? Looks the non-LTO speed is slightly
> faster, but still not much. Thus the patch looks promising.

I don't have a good handle on that issue yet but I'll "test" the
patch shortly so firefox is fixed.

I suspect the best approach is to generate the ref DIEs lazily
on lookup... (this could get really messy though).


More information about the Gcc-bugs mailing list