This is the mail archive of the
mailing list for the GCC project.
Re: gcc 3.5 integration branch proposal
Geoffrey Keating <email@example.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.