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] Put CFG into GGC memory


On Tue, 2003-12-02 at 10:11, Steven Bosscher wrote:
> > 
> >     /* Instructions queued on the edge.  */
> > !   union edge_def_insns {
> >       rtx r;
> >       tree t;
> > !   } GTY ((skip (""))) insns;
> > 
> >  
> >     /* Auxiliary info specific to a pass.  */
> > !   PTR GTY ((skip (""))) aux;
> >   
> 
> I thought the whole point of making the CFG garbage collectable was that it
> would expose the code in the basic blocks to the GC marker routines.  What's
> really needed here is some kind of flag (enum?) to indicate what mode the CFG
> is in, and then use tags to say what can hang from the insns and aux fields of
> a basic block.
> 
> > *************** struct bb_ann_d
> > *** 313,319 ****
> >     int num_preds;
> >   
> >     /* Set of blocks immediately dominated by this node.  */
> > !   bitmap dom_children;
> >   
> >     /* Nonzero if this block is forwardable during cfg cleanups.  This is also
> >        used to detect loops during cfg cleanups.  */
> > --- 313,319 ----
> >     int num_preds;
> >   
> >     /* Set of blocks immediately dominated by this node.  */
> > !   bitmap GTY ((skip (""))) dom_children;
> >   
> >     /* Nonzero if this block is forwardable during cfg cleanups.  This is also
> >        used to detect loops during cfg cleanups.  */
> 
> Why not just make dom_children GGC allocated as well?  Same for all the regset
> bitmaps in the basic_block_def struct.
> 

It feels to me like we are running around like chickens with no heads at
the moment regarding memory allocation.  I have no idea what we think
are doing any more, and what if affects. I suspect everyone thinks
something slightly different.

Can we summarize exactly what we think we changing and why? 

I'll start. 

- I am changing the use/def/vuse/vdef operands in stmts to not be
varray's any more. They'll either use their own little manager, or maybe
ggc if they can get their own page and/or a ggc_free maintained list.
That remains to be determined by evaluating it once those functions are
available.  I was originally going to have them share a varray and have
indexes into it, but as that varray grows larger and larger, the copying
a realloc() would do becomes quite hideous. (oh, look a 24 MB operands
varray that we much grow. hmm. ick)

Andrew






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