[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