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 Wednesday 19 November 2003 20:03, law@redhat.com wrote:
> In message <200311191943.43559.s.bosscher@student.tudelft.nl>, Steven Bosscher writes:
>  >> SSA_NAMEs and PHIs have very clear lifetimes.
>  >
>  >Hmmm, not much clearer than basic blocks AFAICT, at least, not for the
>  > tree cfg.
>
> Disagree strongly.  SSA_NAMEs and PHI nodes have a lifetime that starts
> at the beginning of rewrite_into_ssa and ends at the end of
> rewrite_out_of_ssa. Some changes I'm working on will make that even clearer
> since those changes recycle SSA_NAMEs during that lifetime (and we'll
> probably recycle PHIs too).
>
> Contrast this to a block.  A block could life within the tree passes,
> within the rtl passes, or possibly across both!

Well not across both right now, I thought the debate is still on :-P

Seriously, I can't follow your reasoning here.  We know _exactly_ when a
block or an edge dies right now.  How much clearer can it be?  On the 
other hand, SSA names and PHI nodes, or any other tree for that matter,
were made garbage collectable because we _dont_ know anything about their
life span.

OK, so for SSA names and PHI nodes you can say that they live between the
into-SSA and out-of-ssa passes.  They could also die (or even be created
in between). That's not nearly as accurate as explicit calls to create_bb()
remove_bb().

But that wasn't the point.  What I wanted to say is that some mechanism to
control the pages in which you're allocating GC-able objects is generally
useful, not just for short-lived objects.  For the latter, it allows you
to sweep 'm all at some point.  For long lived objects that are known to
belong together, it can be useful to collect them close together for
locality.
(Of course you could say that for long-lived objs you shouldn't GC in the
first place.  But that's not how GC in GCC works :-/ )

But I'm starting to repeat myself too often, so I'll just shut tf up now or
actually implement something ;-)

Gr.
Steven


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