This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa PATCH] Pick memory consumption low hanging fruit
- From: Andrew MacLeod <amacleod at redhat dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Steven Bosscher <s dot bosscher at student dot tudelft dot nl>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: 18 Nov 2003 17:28:04 -0500
- Subject: Re: [tree-ssa PATCH] Pick memory consumption low hanging fruit
- References: <200311181955.hAIJtdwg001593@speedy.slc.redhat.com>
On Tue, 2003-11-18 at 14:55, email@example.com wrote:
> In message <1069178528.30709.60.camel@p4>, Andrew MacLeod writes:
> >On Tue, 2003-11-18 at 11:32, firstname.lastname@example.org wrote:
> >> In message <email@example.com>, Steven Bossc
> [ ... ]
> >Without PRE and DOM:
> >stmts 75370 2418556
> >exprs 1629048 54715048
> >phi_nodes 215615 11616040
> >ssa names 728089 23298848
> >Total 5615988 192490948
> >without PRE (so including DOM):
> >stmts 75760 2431036
> >exprs 2337733 80258208
> >phi_nodes 323388 17225448
> >ssa names 1048212 33542784
> >Total 6745718 233635736
> OK. So consider 600+k of the expr nodes gone with a savings of ~23M. All
> stuff that would have been GC'd, but it's insanely stupid to generate that
> many garbage nodes due to lameness in how we record synthetic equivalences.
> As expected, the increase in phi nodes and ssa names is directly related
> to the need to re-rewrite variables after munging the CFG in fun and
> interesting ways due to jump threading. Finding a way to re-use the existing
> SSA_NAME nodes and/or PHI nodes would get us another 15M or so.
Thats overall. If we collected between passes, or free'd SSAisms, or
something along those lines, it wouldn't be as bad from function to
function. Sure we'd have a highwater mark, but it wouldnt push the
envelope as much. Is there a reason we dont collect bewteen functions?
we know both SSA and RTL aren't going to carry over fom one function to
the next. (Don't we?? :-)
Sigh. I dont suppose there would be a simple way to combine GC and a
machanism for using GC memory, yet knowing when we are done with memory.
When we get rid of a PHI node, we know we're done with it. It would be
awful nice if we could say we're done with this, so it get put on a free
list, and used the next time we need a PHI node. It seems silly to
ignore this kind of information simply because we have agarbage
colector that will figure it out for us.So have GC, and GC_free()..