This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]