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: [tree-ssa PATCH] Pick memory consumption low hanging fruit


On Tue, 2003-11-18 at 14:55, law@redhat.com wrote:
> In message <1069178528.30709.60.camel@p4>, Andrew MacLeod writes:
>  >On Tue, 2003-11-18 at 11:32, law@redhat.com wrote:
>  >> In message <200311181219.41900.s.bosscher@student.tudelft.nl>, 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()..

Andrew

Amndrew


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