This is the mail archive of the gcc-patches@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: C++: Mark the last use of nested_p for t_r_o_c as dead


On Mon, Sep 06, 2004 at 03:43:46PM -0700, Geoffrey Keating wrote:
> Daniel Jacobowitz <drow@false.org> writes:
> 
> ...
> > That leaves exactly one call to ggc_push_context, in cse.c.  The
> > most ever allocated in the subcontext, building all of cc1-i-files
> > (and -ii-files :), is 870K - usual amounts are more like 15K (I
> > think that the spike is insn-attrtab.i).  Removing the ggc_collect
> > within CSE and removing all of the ggc_push_context /
> > ggc_pop_context infrastructure would be a win.  If we need to re-add
> > this, it will hopefully be enough to have push/pop keep a depth
> > counter and refuse to collect in lower depths.
> > 
> > My motivation is that the push/pop is expensive for ggc-page, and extremely
> > expensive for ggc-zone (not in its current incarnation, but in its current
> > incarnation it doesn't work correctly either).  Does this sound reasonable?
> 
> My understanding is that ggc_collect was placed there because there
> are some cases where CSE can really create lots of garbage.  However,
> that was before we had tree-ssa, so maybe it can't now.  It would be
> profitable to look up the history of that ggc_collect, I am sure there
> was something on the mailing lists about it.
> 
> It would be *really neat* to remove ggc_push_context!

I did do a little bit of the research before I posted the patch, but
there wasn't enough to bother summarizing.  It was added in 1999, and
the calls to push/pop the context were added in 2000.  I did a little
more... here's the patch:
  http://gcc.gnu.org/ml/gcc-patches/1999-09n/msg00482.html

Jim agrees with what Mark just told me:
  http://gcc.gnu.org/ml/gcc-patches/1999-09n/msg00524.html

I have access to Plum Hall, but I'm not set up to run it right now, so
I can't retry the test in question.  But I took a look at it, and I'd
be amazed if the tree optimizers couldn't kill most of it right off the
bat.  I think that while the RTL optimizers still hold value, they
shouldn't be encountering the humongous workloads that made this
necessary.

I have verified that the remaining call in tree-optimize.c is now dead
code, and I've convinced myself, at least, that the one in CSE is no
longer necessary.  I don't think there will be further need for context
pushing related to either function nesting (now handled via cgraph), or
existing optimizers (new optimizers can be written to avoid it without
much additional burden; old optimizers we'd have noticed by now). 
Therefore I believe we can kill pushing and popping of contexts.  FWIW,
it's good for a measurable speedup on the revised zone allocator I'm
still working on.

-- 
Daniel Jacobowitz


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