https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Richard Biener from comment #6) > I wonder where the main _int_malloc load comes from. To answer this question myself, 84% from the _int_malloc load comes from calling malloc of which 55% comes from calling xmalloc (27% xrealloc, 12% operator new), of which there is quite an even distribution amongst callers, alloc-pool.c and obstack.c as acummulators on the top, sbitmap allocations are also high in the list. callgrind thinks _obstack_begin and pool_alloc are the top ones cost-wise with some large gap to the thrid place. _obstack_begin is mostly called from bitmap obstack init which is then reasonably distributed. alloc-pools are mostly used by the DF and DOM (et-forest) machineries. xrealloc is vec<>s, operator new is SCEV. tramp3d has a lot of functions thus we gobble up many one-per-function or one-per-pass allocations. But even callgrind confirms that _int_malloc is the 3rd costly function (as of "self" cost, w/o callees). But unfortunately there is nothing obvious to cut off a significant amount of the allocation load.
