This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 04 Mar 2015 09:10:50 +0000
- Subject: [Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression
- Auto-submitted: auto-generated
- References: <bug-65076-4 at http dot gcc dot gnu dot org/bugzilla/>
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.