This is the mail archive of the
mailing list for the GCC project.
Re: gcc 3.5 integration branch proposal
On 20/01/2004, at 10:04 AM, Zack Weinberg wrote:
Jan Hubicka <firstname.lastname@example.org> 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
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.
You're looking at this the wrong way. We have to load the object into
cache anyway, it does not really matter if make_node does it or it's
I'll emphasize Jan's comment: when you analyze GCC performance, you can
usually disregard all code that doesn't cause cache faults.