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


Geoffrey Keating <geoffk@apple.com> writes:
>> 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.

I think you misunderstand what I was saying, or else my testing is on
chips with very different cache behavior.

The current effect is, make_node loads and zeroes the entire node, and
then most fields of that are rewritten with live data.  I don't have
numbers to say what that does for trees, but I know that cpplib used
to do similar things to its own data structures, and changing it not
to was good for an overall 1-2% on wall clock time running gcc -E.

Fundamentally, cutting down the write traffic even just to L1 can't be
a bad thing.

zw


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