https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119705
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> --- Created attachment 61061 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61061&action=edit -fmem-report with detailed-mem-stats and -g Using -g instead of -fsyntax-only (which will bring us to 10GB max RSS) adds to this dwarf2out.cc:5825 (new_die_raw) 277M: 4.3% 1124k: 0.0% 0 : 0.0% 0 : 0.0% 3564k dwarf2out.cc:4486 (add_dwarf_attr) 1004M: 15.6% 2361k: 0.0% 279M: 5.8% 37M: 3.3% 4881k but also the hashes dwarf2out.cc:29790 (dwarf2out_init) 15M: 14.6% 23M 18 : 0.0% ggc dwarf2out.cc:4736 (find_AT_string) 23M: 21.9% 27M 31 : 0.0% ggc I'll note that the die->die_attr is inefficient since dw_attr_node is typedef struct GTY(()) dw_attr_struct { enum dwarf_attribute dw_attr; dw_val_node dw_attr_val; } dw_attr_node; and struct GTY(()) dw_val_node { enum dw_val_class val_class; struct addr_table_entry * GTY(()) val_entry; union dw_val_struct_union { ... GTY ((desc ("%1.val_class"))) v; }; there's two 4 byte holes after the enums, the whole thing is 40 bytes instead of 32. Adding to the GC allocated attr vector with vec_safe_reserve (, 1) allocates space for 4 elements up-front, statistics on the number of attributes on DIEs (when there is one) would be nice to have. A DIE itself is "only" 80 bytes.
