Re: RFC: support for multiple CFGs (necessary for the tree-profiling branch)

[Jan Hubicka <jh at suse dot cz>]

> On Mon, May 24, 2004 at 10:01:56PM +0200, Steven Bosscher wrote:
> > On Monday 24 May 2004 21:48, Stuart Hastings wrote:
> > > On May 24, 2004, at 9:38 AM, Richard Henderson wrote:
> > > > On Sun, May 23, 2004 at 11:00:29PM +0200, Steven Bosscher wrote:
> > > >> +#define ENTRY_BLOCK_PTR(FN)            ((FN)->cfg->entry_block_ptr)
> > > >> +#define EXIT_BLOCK_PTR(FN)             ((FN)->cfg->exit_block_ptr)
> > > >> +#define BASIC_BLOCK_INFO(FN)           ((FN)->cfg->basic_block_info)
> > > >> +#define N_BASIC_BLOCKS(FN)             ((FN)->cfg->n_basic_blocks)
> > > >> +#define N_EDGES(FN)                    ((FN)->cfg->n_edges)
> > > >> +#define LAST_BASIC_BLOCK(FN)           ((FN)->cfg->last_basic_block)
> > > >> +#define LABEL_TO_BLOCK_MAP(FN)
> > > >> ((FN)->cfg->label_to_block_map)
> > > >
> > > > It would seem to be an easier change to imply cfun in these macros
> > > > and to use a separate set (or none at all) for the rare case of
> > > > having to access a different function's cfg.
> > >
> > > Sounds like you'd prefer what I had originally:
> > >
> > > 	#define ENTRY_BLOCK_PTR ENTRY_BLOCK_PTR_FN(cfun)
> > >
> > > Others similar.
> > 
> > We discussed this before and you know Honza and I would prefer
> > that the even the default cfg object is referenced explicitely.
> > Reasons for this are:
> > - Make it explicit that we work on the CFG of the current
> >   function.  In your proposed patch this is not the case.
> 
> True...
> 
> > - Not having the function as an argument to these macros
> >   that replace the global variables is inconsistent: it
> >   makes things look like parts of the compiler knows only
> >   about one CFG, and other parts know that there are many
> >   CFGs around.
> 
> But that's exactly right!
> 
> That's why I proposed the "default cfun" and "parameterized" versions
> of the macros.  Most of the existing GCC sources don't care and don't
> want to know that multiple CFGs exist.
> 
> For example, the FOR_BB_BETWEEN macro will now need five parameters.
> I personally have mental difficulties with anything that takes more
> than three parameters.  :-)  More is not always better.
> 
> I'm not overly concerned how this comes out, but I'll respectfully
> point out that today, only Callgraph and Inliner are currently aware
> that "other functions have callgraphs."  As GCC evolves, I suppose an
> intermodular something-or-another will want to reference multiple
> CFGs.  But Callgraph, Inliner, and IMA combined will always be a tiny
> minority of the GCC sources.
> 
> > Honza even said he would like to slowly move all of the CFG
> > manipulation API to take the CFG pointer as an argument,
> 
> (You mean the DECL_STRUCT_FUNCTION() value, right?)
> 
> > so we
> > can operate on multiple CFG objects transparently.  I agree this
> > is the right thing to do.
> > I also asked rth on IRC if he feels strongly about not taking
> > the function as an argument, and he does not, so I plan to commit
> > my patch as-is.
> 
> O.K., whatever.
> 
> > > I plan to fold the 'cfg' struct back into 'struct function'; there's no
> > > benefit to having them be separate (eliminating the "->cfg" in the
> > > fragment above).

One of benefits is that we don't allocate ->cfg for everything that has
struct function allocated - C++ frontend allocate struct function for
templates, dead functions and other stuff and it acounts over 17% of
resident memory for POOMA.  In future I would like to break up the
struct function to parts that have different lifetimes so I would
preffer cfg related things to stay together.
Having cfun.cfg would be fine for me for now tought as long as the
accestors are hidden in the macros

Honza
> > 
> > That is probably a good idea, but it requires that we include
> > basic-block.h and varray.h in every file that includes function.h,
> > or that we move basic_block_def (and edge_def, block_reorder_def ?)
> > to coretypes.h.  Not sure if _that_ is a good idea.  I didn't look
> > at it much, though.
> 
> This sounds like a good question for The List:
> 
> Q: If we fold the proposed "control_flow_graph" struct into "struct
> function," then everybody that #includes function.h will see all of
> basic-block.h.  O.K., or Bad Idea?
> 
> stuart hastings
> Apple Computer