This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc 3.5 integration branch proposal
Jan Hubicka <hubicka@ucw.cz> writes:
>> I am not sure why ggc_alloc comes in second; checking is disabled so
>
> My experience from oprofiling is, that ggc_alloc/garbage
> collector/memset is where all our cache faults go, so they end up
> high in profiles even when amount of work looks small. It is not
> really ggc_alloc fault, rather it is the fact that we use too much
> of it.
True.
One cause of excessive memset that I have wanted to address for years
is, make_node() clears the entire tree node - but make_node is almost
always called from somewhere that's going to fill in most or all of
the fields anyway. We ought to have something like the gen_rtx_fmt_*
functions for tree nodes.
> I am working on some of these :)
> One other major stopper you don't see on your profile is
> for_each_template_parm that can eat about 10% when compiling Gerald's
> application with optimizing.
Oh, it's there even on this test case. It's down at #54 on the call
graph, but it's responsible for two-thirds of the htab usage, which
you can see at the top of the profile.
zw