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

[Stuart Hastings]

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