This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa PATCH] Pick memory consumption low hanging fruit
- From: Steven Bosscher <s dot bosscher at student dot tudelft dot nl>
- To: law at redhat dot com
- Cc: Andrew MacLeod <amacleod at redhat dot com>,gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 19 Nov 2003 19:43:43 +0100
- Subject: Re: [tree-ssa PATCH] Pick memory consumption low hanging fruit
- References: <200311191809.hAJI9LBH009988@speedy.slc.redhat.com>
On Wednesday 19 November 2003 19:09, email@example.com wrote:
> In message <firstname.lastname@example.org>, Steven
> >> 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