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 Wednesday 19 November 2003 19:09, wrote:
> In message <>, Steven
> Bosscher
> writes:
>  >> However, I do really like the idea of allocating all the SSA_NAMEs and
>  >> PHI_NODEs in their own pages/zones. so we'd need a ggc_alloc_ssatree()
>  >> call for those I guess.  VDEF, EEXIT, EKILL, EUSE and EPHIs would fall
>  >> into that category/zone as well.
>  >
>  >It's been said before: some way to allocate in specific pages would
>  > generally
>  >
>  >be useful, not just for PHIs and SSA names.  Also basic blocks, edges,
>  >objects for which you _know_ they won't live very long, etc.

... and for objects which you want to keep together because you know they will 
usually be accessed as a group (ie. locality).

> Err, basic blocks and edges have a long lifetime -- in fact I don't believe
> you can necessarily determine the lifetime of a block or edge object.

Right.  Does my addition above fix this?  :-)

I would like to make bbs/edges GC-able.  We _must_ make them GC-able or we'll 
never be able to collect garbage between passes (or we must come up with a 
way to mark all GC-able objects that hang from non-GC-able objects, but 
that's way too ugly IMO.)

> SSA_NAMEs and PHIs have very clear lifetimes.

Hmmm, not much clearer than basic blocks AFAICT, at least, not for the tree 


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