This is the mail archive of the 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, wrote:
> In message <1069178528.30709.60.camel@p4>, Andrew MacLeod writes:
>  >On Tue, 2003-11-18 at 11:32, wrote:
>  >> In message <>, 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()..



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