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: RFC: support for multiple CFGs (necessary for the tree-profiling branch)


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.
- 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.
  
Honza even said he would like to slowly move all of the CFG
manipulation API to take the CFG pointer as an argument, 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.


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

Gr.
Steven



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