This is the mail archive of the gcc@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][ GC, Virtual operands, and GCing between passes


> X-Original-To: geoffk@foam.wonderslug.com
> From: Andrew MacLeod <amacleod@redhat.com>
> Cc: gcc mailing list <gcc@gcc.gnu.org>
> Date: 11 Dec 2003 12:09:24 -0500
> X-OriginalArrivalTime: 11 Dec 2003 17:01:50.0062 (UTC) FILETIME=[77EA48E0:01C3C008]
> 
> On Thu, 2003-12-11 at 11:59, Geoff Keating wrote:
> > Andrew MacLeod <amacleod@redhat.com> writes:
> > 
> > > I have array of pointers to trees.
> > > 
> > > so 
> > > 
> > > tree **defs;
> > 
> > That's an array of pointers to pointers to trees.  'tree' is a pointer
> > to a tree.
> > 
> 
> Depends on how you descibe it. 'tree' is a pointer to a tree
> structure/union so  Its an array of pointers to pointers to tree
> structures, yes, but an array of pointers to trees seemed like a
> sufficient description to me... 
> 
> regardless, Its a cache of all the operand pointers in the stmt. So its
> a list of pointers to trees so we can access/change them easily without
> hunting for them. thus 'tree **'.
> 
> So all the trees will get marked when the stmt is marked. Since the
> vector is part of the stmt annotation, if the stmt operands are not
> marked, the annotation/vector will not get marked either. If the stmt is
> marked, I need the vector to be marked, but none of the components.
> 
> So I need the tree ** vector to be treated as if is an array of
> interegers or something, no marking of anything in it.

Right.  gengtype is specifically designed to prevent you from doing
this, because it's usually a mistake.  For instance:

- If you're wrong about the lifetime of the objects, you'll end up
  with dangling pointers, which GC is supposed to prevent.  For
  instance, if someone rearranges the stmt (maybe by doing some
  constant folding) and then calls ggc_collect without updating the
  defs structure.
- You cannot save objects like this with PCH.
- A future compacting collector will not work if you do this.

If you still think this is a good idea, why not just try:

intptr_t * defs_p;

?

> Im about to punt on it anyway and manage those vectors myself since GC
> doesnt seem to want to deal with them nicely.



-- 
- Geoffrey Keating <geoffk@geoffk.org>


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