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 rguent...@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. > > > 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% > > 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.
