RE: [tree-ssa][ GC, Virtual operands, and GCing between passes

RE: [tree-ssa][ GC, Virtual operands, and GCing between passes

[S. Bosscher]

> The problem is that gengtype will not allow me to have vevotrs of type
> tree **. It says its an unknown type.
> 
> typedef struct def_optype_d GTY(())
> {
>   unsigned num_defs;
>   tree ** defs;
> } def_optype_t;

Try this with http://gcc.gnu.org/ml/gcc-patches/2003-12/msg00593.html.

If that doesn't work, make it "PTR * GTY((skip ())) defs" (or just
"void **" if you have that patch applied anyway) and cast to tree
where needed.

Gr.
Steven

RE: [tree-ssa][ GC, Virtual operands, and GCing between passes

[Andrew MacLeod]

On Thu, 2003-12-11 at 09:14, S. Bosscher wrote:
> > The problem is that gengtype will not allow me to have vevotrs of type
> > tree **. It says its an unknown type.
> > 
> > typedef struct def_optype_d GTY(())
> > {
> >   unsigned num_defs;
> >   tree ** defs;
> > } def_optype_t;
> 
> Try this with http://gcc.gnu.org/ml/gcc-patches/2003-12/msg00593.html.
> 
> If that doesn't work, make it "PTR * GTY((skip ())) defs" (or just
> "void **" if you have that patch applied anyway) and cast to tree
> where needed.
> 
But when I use skip:
  
ptr * GTY((skip(""))) defs, 

its doesn't mark the vector, so it gets stomped all over. :


    typedef struct def_optype_d GTY(())
    {
      unsigned num_defs;
      tree * GTY((skip(""))) defs;
    } def_optype_t;

produces:

void
gt_ggc_mx_operands_d (void *x_p)
{
  struct operands_d * const x = (struct operands_d *)x_p;
  if (ggc_test_and_set_mark (x))
    {
    }
}


So that doesn't work for me either.

I am lothe to use the other patch until it is accepted by someone. OH, I
see Jim OK'd it. Has it been checked into mainline or the tree-ssa
branch?

Andrew

RE: [tree-ssa][ GC, Virtual operands, and GCing between passes

[Andrew MacLeod]

On Thu, 2003-12-11 at 09:27, Andrew MacLeod wrote:
> On Thu, 2003-12-11 at 09:14, S. Bosscher wrote:
> > > The problem is that gengtype will not allow me to have vevotrs of type

> 
> 
> So that doesn't work for me either.
> 
> I am lothe to use the other patch until it is accepted by someone. OH, I
> see Jim OK'd it. Has it been checked into mainline or the tree-ssa
> branch?
> 

Even with the patch I still get:
./gengtype
warning: structure `java_line' used but not defined
warning: structure `jdeplist_s' used but not defined
warning: structure `java_lexer' used but not defined
warning: structure `ZipDirectory' used but not defined
warning: structure `aterm_list_a' used but not defined
warning: structure `aterm_' used but not defined
/src/tree-ssa/2003-12-10-new/gcc/gcc/tree-ssa-operands.h:30: field
`(*x).def_ops.defs' is pointer to unimplemented type
/src/tree-ssa/2003-12-10-new/gcc/gcc/tree-ssa-operands.h:38: field
`(*x).use_ops.uses' is pointer to unimplemented type

typedef struct def_optype_d GTY(())
{
  unsigned num_defs;
  void * GTY(()) defs;
} def_optype_t;

or
typedef struct def_optype_d GTY(())
{
  unsigned num_defs;
  void * defs;
} def_optype_t;
or
ypedef struct def_optype_d GTY(())
{
  unsigned num_defs;
  void **GTY(()) defs;
} def_optype_t;

etc.

Re: [tree-ssa][ GC, Virtual operands, and GCing between passes

[Andrew MacLeod]

On Mon, 2003-12-15 at 17:04, Richard Henderson wrote:
> On Thu, Dec 11, 2003 at 06:13:00PM -0500, Andrew MacLeod wrote:
> > > - A future compacting collector will not work if you do this.
> > 
> > Why not? Its still just an arbitrary vector of size N...
> 
> Because the objects that you've internal pointers to will move.
> 
> Anyway, yer screwed by a compacting collector anyway, since 
> unless you want to slow down your collector significantly, you
> can't have pointers into the *middle* of objects at all.
> 
> For now the best solution would seem to be "void *defs_p" and
> cast to the proper pointer type when you use it.  If the GC
> marker can't deal with "void *", then it needs to be fixed.
> 
> If we ever implement a compacting collector, we'll have to 
> come up with some other way to represent this.  Possibly we
> could do something with either paths down from the statement,
> or <tree,operand> pairs.

Ive got a new best solution which will allow me to use gc, so I dont
have this problem anymore :-)

Andrew

Re: [tree-ssa][ GC, Virtual operands, and GCing between passes

[Richard Henderson]

On Thu, Dec 11, 2003 at 06:13:00PM -0500, Andrew MacLeod wrote:
> > - A future compacting collector will not work if you do this.
> 
> Why not? Its still just an arbitrary vector of size N...

Because the objects that you've internal pointers to will move.

Anyway, yer screwed by a compacting collector anyway, since 
unless you want to slow down your collector significantly, you
can't have pointers into the *middle* of objects at all.

For now the best solution would seem to be "void *defs_p" and
cast to the proper pointer type when you use it.  If the GC
marker can't deal with "void *", then it needs to be fixed.

If we ever implement a compacting collector, we'll have to 
come up with some other way to represent this.  Possibly we
could do something with either paths down from the statement,
or <tree,operand> pairs.



r~

Re: [tree-ssa][ GC, Virtual operands, and GCing between passes

[law]

In message <1071236019.14001.14.camel@p4>, Andrew MacLeod writes:
 >It worked before because its a variable sized array at the end of the
 >varray structure, and doesnt have to have its elements marked.
 >so it would be sized as 
 >
 >SIZEOF VARRAY_HDR + sizeof (tree *) * num_elements
 >
 >and  the head of the varray is marked, and everything is wonderful.
 >
 >I am using exactly the same representation, except Im trying to
 >dynamically allocate the array insead of having the overhead of the
 >varray structure.
Ahhhh.  OK.


jeff

Re: [tree-ssa][ GC, Virtual operands, and GCing between passes

[Andrew MacLeod]

On Thu, 2003-12-11 at 22:58, law@redhat.com wrote:
> In message <1071199658.5712.571.camel@p4>, Andrew MacLeod writes:
>  >If it was just tree *def, we would have access to read the defs and
>  >uses, but if we wanted to actually change the value of the def or use
>  >operands in the originating stmt, you dont have a handle on the pointer
>  >in the stmt which points at that operand, so you cant change it without
>  >structure copying the tree structure.And we dont want to do that :-)
>  >tree **def lets us get a tthe things which points at the operand.
> Then how did it work previously with use_ops & def_ops?  I'm pretty sure
> we can replace uses & defs within that framework and my recollection was
> that it simply used a varray of tree *.
> 

Yessssssss....  

a varray of tree *... what is the data structure at the end of the
varray_type structure for a TREE_PTR varray?

tree *tp[1]

which is the same type as  my tree **tp, except its an in place array
instead of a dynamically allocated array.

It worked before because its a variable sized array at the end of the
varray structure, and doesnt have to have its elements marked.
so it would be sized as 

SIZEOF VARRAY_HDR + sizeof (tree *) * num_elements

and  the head of the varray is marked, and everything is wonderful.

I am using exactly the same representation, except Im trying to
dynamically allocate the array insead of having the overhead of the
varray structure.

I havent actually changed anything.

I could probably make it work with GC by declaring it as 

struct def_vector GTY(()) {
  tree * GTY((skip(""))) defs[1];
}

struct def_optype GTY(()) {
  size_y num_defs;
  struct def_vector *defs;
}

and then sizing it appropriately when malloced, but again, Im going
through contortions to make it work, My pointer to this structure will
in effect be a tree ** even though it will only be declared as a struct
'def_vector *'

I suppose I could even do it exactly the same as a varray:
struct def_optype GTY(()) {
  size_y num_defs;
  tree *def[1];
}

and size that one when malloced, except at the moment this structure
isnt malloced.

I may indeed contemplate doing that in fact, but it still doesnt change
the type of the def vector... 

Andrew

Re: [tree-ssa][ GC, Virtual operands, and GCing between passes

[law]

In message <1071199658.5712.571.camel@p4>, Andrew MacLeod writes:
 >If it was just tree *def, we would have access to read the defs and
 >uses, but if we wanted to actually change the value of the def or use
 >operands in the originating stmt, you dont have a handle on the pointer
 >in the stmt which points at that operand, so you cant change it without
 >structure copying the tree structure.And we dont want to do that :-)
 >tree **def lets us get a tthe things which points at the operand.
Then how did it work previously with use_ops & def_ops?  I'm pretty sure
we can replace uses & defs within that framework and my recollection was
that it simply used a varray of tree *.

vuses and vdefs are varrays of trees.

I think you've got one too many levels of indirection.

jeff

Re: [tree-ssa][ GC, Virtual operands, and GCing between passes

[Andrew MacLeod]

On Thu, 2003-12-11 at 18:34, law@redhat.com wrote:
> In message <1071184128.14253.289.camel@p4>, Andrew MacLeod writes:
>  >On Thu, 2003-12-11 at 14:30, law@redhat.com wrote:
>  >> In message <1071016677.17667.2918.camel@p4>, Andrew MacLeod writes:
>  >>  >
>  >>  >I have array of pointers to trees.
>  >>  >
>  >>  >so 
>  >>  >
>  >>  >tree **defs;
>  >> Really pointers to pointers to trees.
>  >> 
>  >> 
>  >>  >I don't want what defs points to to be marked, since they are marked
>  >>  >otherwise, I just need the defs vector itself collected:
>  >> Is that really the reason why you're going through these contortions?  Does
>  >> it really buy us any measurable improvement?
>  >> 
>  >
>  >ACtually, no, the contortions are just to get the GC system to *let* me
>  >have this vector. I have since punted.
> Hmmm, don't we just need an array of pointers to trees?  ie
> 
> tree *defs?
> 
> instead of
> 
> tree **defs?
> 
> Or am I missing something?


If it was just tree *def, we would have access to read the defs and
uses, but if we wanted to actually change the value of the def or use
operands in the originating stmt, you dont have a handle on the pointer
in the stmt which points at that operand, so you cant change it without
structure copying the tree structure.And we dont want to do that :-)
tree **def lets us get a tthe things which points at the operand.

vdefs and vuses are the actual tree value, so an array of trees works
for them. They dont occur anywhere else. We have one extra level of
indirection for stmt real operands.

Andrew

Re: [tree-ssa][ GC, Virtual operands, and GCing between passes

[law]

In message <1071184128.14253.289.camel@p4>, Andrew MacLeod writes:
 >On Thu, 2003-12-11 at 14:30, law@redhat.com wrote:
 >> In message <1071016677.17667.2918.camel@p4>, Andrew MacLeod writes:
 >>  >
 >>  >I have array of pointers to trees.
 >>  >
 >>  >so 
 >>  >
 >>  >tree **defs;
 >> Really pointers to pointers to trees.
 >> 
 >> 
 >>  >I don't want what defs points to to be marked, since they are marked
 >>  >otherwise, I just need the defs vector itself collected:
 >> Is that really the reason why you're going through these contortions?  Does
 >> it really buy us any measurable improvement?
 >> 
 >
 >ACtually, no, the contortions are just to get the GC system to *let* me
 >have this vector. I have since punted.
Hmmm, don't we just need an array of pointers to trees?  ie

tree *defs?

instead of

tree **defs?

Or am I missing something?

Jeff

Re: [tree-ssa][ GC, Virtual operands, and GCing between passes

[Andrew MacLeod]

On Thu, 2003-12-11 at 15:19, Geoff Keating wrote:

> > 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.

Its part of the stmt, once the stmt is modified, the modified bit is set
in the annotation, and all the pointers are implicitly invalidated.
Before the operands can be accessed, these caches are rebuilt with new
ones.

> - You cannot save objects like this with PCH.

Its only live for the duration of SSA. It allvanishes when SSA is
destroyed.

> - A future compacting collector will not work if you do this.

Why not? Its still just an arbitrary vector of size N...

> 
> 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.

I've bypassed it for now. There is no need for it to be handled by GC,
so I'll let it be for now. I might want to revisit it when we get a
working zone collector, but for now what I have will do.

Andrew

Re: [tree-ssa][ GC, Virtual operands, and GCing between passes

[Andrew MacLeod]

On Thu, 2003-12-11 at 14:30, law@redhat.com wrote:
> In message <1071016677.17667.2918.camel@p4>, Andrew MacLeod writes:
>  >
>  >I have array of pointers to trees.
>  >
>  >so 
>  >
>  >tree **defs;
> Really pointers to pointers to trees.
> 
> 
>  >I don't want what defs points to to be marked, since they are marked
>  >otherwise, I just need the defs vector itself collected:
> Is that really the reason why you're going through these contortions?  Does
> it really buy us any measurable improvement?
> 

ACtually, no, the contortions are just to get the GC system to *let* me
have this vector. I have since punted.

> I wouldn't expect a huge overhead to check the mark on an object that we
> marked via some other chain of pointers.  But hey, maybe I'm wrong :-)
> 

It doesnt know how to mark a tree ** type.  Even if it did that, I
wouldn't care much.

Anyway, I have a quick an dirty solution wuthout using GC for this that
lets me do some reusing.

We can visit it later if need be.
Andrew

Re: [tree-ssa][ GC, Virtual operands, and GCing between passes

[Geoff Keating]

> 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>

Re: [tree-ssa][ GC, Virtual operands, and GCing between passes

[law]

In message <1071016677.17667.2918.camel@p4>, Andrew MacLeod writes:
 >
 >I have array of pointers to trees.
 >
 >so 
 >
 >tree **defs;
Really pointers to pointers to trees.


 >I don't want what defs points to to be marked, since they are marked
 >otherwise, I just need the defs vector itself collected:
Is that really the reason why you're going through these contortions?  Does
it really buy us any measurable improvement?

I wouldn't expect a huge overhead to check the mark on an object that we
marked via some other chain of pointers.  But hey, maybe I'm wrong :-)

jeff

Re: [tree-ssa][ GC, Virtual operands, and GCing between passes

[law]

In message <1070998524.17667.2860.camel@p4>, Andrew MacLeod writes:
 >
 >
 >Are we sure we want to GC between passes? :-|
Yes :-)


 >since VDEFs and VUSEs are tree nodes, I can't allocate the structure
 >which holds them anywhere except GC'd memory can I?
Huh?  Presumably turning them into tree nodes (they aren't currently
tree nodes) buys you something?

Certainly if they are tree nodes, then they need to be allocated by the
GC system and be reachable from GC roots.


 >struct v_operands_d *vops;
 >
 >struct v_operands_d {
 >  unsigned int num
 >  tree *vec;
 >}
 >
 >so I dont want the memory associated with either  'vops' or 'vec'
 >garbage collected, but I do want to keep around anything that
 >vec[0]..vec[num-1] points to.
 >
 >Thats not really going to work too well is it? At least I haven't been
 >able to do it.  So I'll have to keep ggcing the memory for the vops
 >structure?.
I don't think it's going to work.  I'd probably suggest you GC the whole
thing and if necessary, keep a free list of objects you can recycle.

In that kind of scheme, you'd expose the freelist of the GC system as well.

I guess what I really don't understand is why you're trying to not expose
stuff to the GC system.  Is it because we don't have a ggc_free?  Or is
it something else?

Jeff

Re: [tree-ssa][ GC, Virtual operands, and GCing between passes

[Andrew MacLeod]

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.

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

Andrew

Re: [tree-ssa][ GC, Virtual operands, and GCing between passes

[Geoff Keating]

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.

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

Re: [tree-ssa][ GC, Virtual operands, and GCing between passes

[Andrew MacLeod]

On Tue, 2003-12-09 at 18:36, Geoff Keating wrote:
> Andrew MacLeod <amacleod@redhat.com> writes:
> 
> > Are we sure we want to GC between passes? :-|
> > 
> > since VDEFs and VUSEs are tree nodes, I can't allocate the structure
> > which holds them anywhere except GC'd memory can I?
> > 
> > ie
> > 
> > a_3 = VDEF <a_2>
> > 
> > This requires points to 2 trees.
> > 
> > the GC system has to know not to collect the trees I am pointing to in
> > the 2 words of the vdef vector.
> > 
> > but I dont want to GC the vdef vector.
> 

Here is my last remaining problem. I have a hack workaround, but I can't
bootstrap with it because of the warning I get.

The def and use structures contain a vector of tree pointers. This
vector is ggc_alloc()'d, but none of the elements in the vector ought to
be marked.
The problem is that gengtype will not allow me to have vevotrs of type
tree **. It says its an unknown type.

typedef struct def_optype_d GTY(())
{
  unsigned num_defs;
  tree ** defs;
} def_optype_t;


I've tried lots of things. If I use skip(""), then the vector itself
doesn't get collected.  I currently have a hack which works:

typedef struct def_optype_d GTY(())
{
  unsigned num_defs;
  tree * GTY((length("0"))) defs;
} def_optype_t;

and then cast 'defs' to a 'tree **' when it is used. THis performs
exactly what I want. defs get free'd and then no elements are touched
because the loop over the elements has an upper limit of 0, so nothing
happens. Bootstrap fails then because of the warning from the generated
file:

gtype-desc.c: In function `gt_ggc_mx_operands_d':

gtype-desc.c:78: warning: comparison of unsigned expression < 0 is always false
gtype-desc.c:85: warning: comparison of unsigned expression < 0 is always false
gtype-desc.c: In function `gt_pch_nx_operands_d':

if ((*x).def_ops.defs != NULL) {
        size_t i0;
        for (i0 = 0; i0 < (size_t)(0); i0++) {
          gt_ggc_m_9tree_node ((*x).def_ops.defs[i0]);
        }
        ggc_mark ((*x).def_ops.defs);
      }


So what am I suppose to do here? I've tried all the things I can think
of, and nothing seems to work exactly as I want.   How do I tell the
system that tree ** is simply a vector of things to ignore, just mark
the vector?

Andrew

Re: [tree-ssa][ GC, Virtual operands, and GCing between passes

[Andrew MacLeod]

On Tue, 2003-12-09 at 18:36, Geoff Keating wrote:
> Andrew MacLeod <amacleod@redhat.com> writes:
> 
> > Are we sure we want to GC between passes? :-|
> > 
> > since VDEFs and VUSEs are tree nodes, I can't allocate the structure
> > which holds them anywhere except GC'd memory can I?
> > 
> > ie
> > 
> > a_3 = VDEF <a_2>
> > 
> > This requires points to 2 trees.
> > 
> > the GC system has to know not to collect the trees I am pointing to in
> > the 2 words of the vdef vector.
> > 
> > but I dont want to GC the vdef vector.
> 
> Why not?
> 
Ok, so assuming I do it all in GCable form, 

I have array of pointers to trees.

so 

tree **defs;

I don't want what defs points to to be marked, since they are marked
otherwise, I just need the defs vector itself collected:

typedef struct def_optype_d GTY(())
{
  unsigned num_defs;
  tree ** GTY((skip(""))) defs;
} def_optype_t;

If I use skip like this, it doesnt do anything does it?  meaning it
doesnt free defs?

typedef struct def_optype_d GTY(())
{
  unsigned num_defss;
  tree **GTY((length ("%h.num_defs"))) defs;
} vdef_optype_t;

I can tell it how long the vector is but then it claims it doesnt
understand the type "tree **", so it aborts.

Should it look like:

typedef struct def_optype_d GTY(())
{
  unsigned num_defs;
  tree ** GTY((length ("%h.num_vuses"),skip(""))) defs;
} def_optype_t;


or what do I need to do?

Andrew

Re: [tree-ssa][ GC, Virtual operands, and GCing between passes

[Jan Hubicka]

> On Tue, 2003-12-09 at 18:56, Jan Hubicka wrote:
> > > 
> > > 
> > > Are we sure we want to GC between passes? :-|
> 
> > 
> > No, you must manage arrays to be in GGC.  What is preventing you from
> > doing that?
> > 
> 
> Nothing I suppose. Have we got a ggc_free() yet? I was trying to manage
> it sensibly, but if we are gong to have a ggc_free() and a zone
> collector, I probably dont have a lot to gain. At least not enough to
> make it worth any additional trouble.

Yes, this is Steven's favorite task :) Just do expect ggc_free to appear
soon.

Honza
> 
> Andrew

Re: [tree-ssa][ GC, Virtual operands, and GCing between passes

[Andrew MacLeod]

On Tue, 2003-12-09 at 18:56, Jan Hubicka wrote:
> > 
> > 
> > Are we sure we want to GC between passes? :-|

> 
> No, you must manage arrays to be in GGC.  What is preventing you from
> doing that?
> 

Nothing I suppose. Have we got a ggc_free() yet? I was trying to manage
it sensibly, but if we are gong to have a ggc_free() and a zone
collector, I probably dont have a lot to gain. At least not enough to
make it worth any additional trouble.

Andrew

Re: [tree-ssa][ GC, Virtual operands, and GCing between passes

[Jan Hubicka]

> 
> 
> Are we sure we want to GC between passes? :-|
> 
> since VDEFs and VUSEs are tree nodes, I can't allocate the structure
> which holds them anywhere except GC'd memory can I?
> 
> ie
> 
> a_3 = VDEF <a_2>
> 
> This requires points to 2 trees.
> 
> the GC system has to know not to collect the trees I am pointing to in
> the 2 words of the vdef vector.
> 
> but I dont want to GC the vdef vector.
> I have something like:
> 
> struct v_operands_d *vops;
> 
> struct v_operands_d {
>   unsigned int num
>   tree *vec;
> }
> 
> so I dont want the memory associated with either  'vops' or 'vec'
> garbage collected, but I do want to keep around anything that
> vec[0]..vec[num-1] points to.
> 
> Thats not really going to work too well is it? At least I haven't been
> able to do it.  So I'll have to keep ggcing the memory for the vops
> structure?.
Yes.
Everything that points to GGC memory must be GGC alloced too.
> 
> 
> 
> What I'm really trying to avoid is having the actual 'tree *vec' vector
> ggc allocated. I want to mamage the vector allocation myself.
> 
> So I need to mark all the elemnts of vec, but I dont want to mark vec
> itself.
> 
> is that possible?
> 
> right now I have:
> 
>     typedef struct vdef_optype_d GTY(())
>     {
>       unsigned num_vdefs;
>       tree * GTY((length ("%h.num_vdefs"))) vdefs;
>     } vdef_optype_t;
>     
>     typedef struct vuse_optype_d GTY(())
>     {
>       unsigned num_vuses;
>       tree * GTY((length ("%h.num_vuses"))) vuses;
>     } vuse_optype_t;
>     
>     
>     struct voperands_d GTY (())
>     {
>       /* List of VDEF references in this statement.  */
>       struct vdef_optype_d GTY (()) vdef_ops;
>     
>       /* List of VUSE references in this statement.  */
>       struct vuse_optype_d GTY (()) vuse_ops;
>     };
>     
>     <...>
>       /* Virtual operands (VDEF and VUSE).  */
>       struct voperands_d * GTY (()) vops;
>     <...>
> 
> 
> And all the arguments of my vector are being marked, but it is also
> marking 'vuses' and 'vdefs', which I *dont* want to be GC'd.
> 
> Is it possible to do this in any way, shape, or form?

No, you must manage arrays to be in GGC.  What is preventing you from
doing that?

Honza  (feels happy that we was faster with GGCying patch:)
> 
> 
> 
> 
> 
> Andrew
> 

Re: [tree-ssa][ GC, Virtual operands, and GCing between passes

[Geoff Keating]

Andrew MacLeod <amacleod@redhat.com> writes:

> Are we sure we want to GC between passes? :-|
> 
> since VDEFs and VUSEs are tree nodes, I can't allocate the structure
> which holds them anywhere except GC'd memory can I?
> 
> ie
> 
> a_3 = VDEF <a_2>
> 
> This requires points to 2 trees.
> 
> the GC system has to know not to collect the trees I am pointing to in
> the 2 words of the vdef vector.
> 
> but I dont want to GC the vdef vector.

Why not?

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

[tree-ssa][ GC, Virtual operands, and GCing between passes

[Andrew MacLeod]

Are we sure we want to GC between passes? :-|

since VDEFs and VUSEs are tree nodes, I can't allocate the structure
which holds them anywhere except GC'd memory can I?

ie

a_3 = VDEF <a_2>

This requires points to 2 trees.

the GC system has to know not to collect the trees I am pointing to in
the 2 words of the vdef vector.

but I dont want to GC the vdef vector.
I have something like:

struct v_operands_d *vops;

struct v_operands_d {
  unsigned int num
  tree *vec;
}

so I dont want the memory associated with either  'vops' or 'vec'
garbage collected, but I do want to keep around anything that
vec[0]..vec[num-1] points to.

Thats not really going to work too well is it? At least I haven't been
able to do it.  So I'll have to keep ggcing the memory for the vops
structure?.



What I'm really trying to avoid is having the actual 'tree *vec' vector
ggc allocated. I want to mamage the vector allocation myself.

So I need to mark all the elemnts of vec, but I dont want to mark vec
itself.

is that possible?

right now I have:

    typedef struct vdef_optype_d GTY(())
    {
      unsigned num_vdefs;
      tree * GTY((length ("%h.num_vdefs"))) vdefs;
    } vdef_optype_t;
    
    typedef struct vuse_optype_d GTY(())
    {
      unsigned num_vuses;
      tree * GTY((length ("%h.num_vuses"))) vuses;
    } vuse_optype_t;
    
    
    struct voperands_d GTY (())
    {
      /* List of VDEF references in this statement.  */
      struct vdef_optype_d GTY (()) vdef_ops;
    
      /* List of VUSE references in this statement.  */
      struct vuse_optype_d GTY (()) vuse_ops;
    };
    
    <...>
      /* Virtual operands (VDEF and VUSE).  */
      struct voperands_d * GTY (()) vops;
    <...>


And all the arguments of my vector are being marked, but it is also
marking 'vuses' and 'vdefs', which I *dont* want to be GC'd.

Is it possible to do this in any way, shape, or form?





Andrew