https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110489
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed| |2023-06-30
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Samples: 45K of event 'cycles', Event count (approx.): 51356148788
Overhead Samples Command Shared Object Symbol
2.57% 1169 cc1 libc-2.31.so [.] _int_malloc
1.54% 700 cc1 cc1 [.] bitmap_set_bit
1.52% 692 cc1 libc-2.31.so [.] malloc
1.32% 602 cc1 libc-2.31.so [.] _int_free
1.31% 598 cc1 cc1 [.] record_reg_classes
1.04% 476 cc1 cc1 [.] constrain_operands
0.81% 368 cc1 cc1 [.] solve_constraints
0.79% 360 cc1 cc1 [.] cse_insn
0.78% 357 cc1 cc1 [.] ggc_internal_alloc
0.76% 347 cc1 libc-2.31.so [.] free
0.73% 330 cc1 cc1 [.] statistics_fini_pass
it's pointing at things I've seen multiple times, but I think investigating
why memory allocation is so high up in the profile would be good. There
are some users like dom_info::dom_init which hit hard on the allocator
without good reason but then it's only few per function but as seen this
testcase has many of them. Likewise ipa_sra_summarize_function seems to
have 99% cost in memory allocation. Doing more on-demand initialization
might help here.
I have a patch for the statistics_finish_pass hit.
