This is the mail archive of the gcc@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]

Re: gcc 3.5 integration branch proposal



On 20/01/2004, at 10:04 AM, Zack Weinberg wrote:


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.

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 done later.


I'll emphasize Jan's comment: when you analyze GCC performance, you can usually disregard all code that doesn't cause cache faults.


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