Re: [patch, fortran] Make frontend walker more general

[Mikael Morin <mikael dot morin at sfr dot fr>]

Le 13.09.2010 11:51, Jakub Jelinek a écrit :
> On Sat, Sep 11, 2010 at 11:00:30PM +0200, Thomas Koenig wrote:
> > > Furthermore, I think having process_pointer_assign etc. special hooks
> > > is not the right thing for a walker.  IMNSHO you should look e.g. at
> > > walk_tree or perhaps better walk_gimple_stmt.
> > > The walker should call one hook (which takes gfc_code *) at each gfc_code
> > > node, and another hook at each gfc_expr node.  The API should have a way
> > > to stop processing and return some value to the caller, have some void *
> > > pointer passed to the callbacks in which the caller can keep some state,
> > > and have a way how to say that subtrees shouldn't be traversed.
> >
> > Why would this be better?
> >
> > Given the complexity of Fortran, wouldn't this lead to lots of code
> > duplication, with a big switch statement both in the statement walker
> > and the handler for the individual statements?
>
> Because otherwise it isn't a general Fortran FE walker, but quite
> specialized one, and each time you need to handle some code that doesn't
> have a hook or where the hook doesn't have generic enough argument,
> you will need to modify the walker.
>
> I believe in most cases you'll be looking only at a handful of different
> codes, so even if you use a switch stmt in the hook, it will be small enough
> that it will be implemented using a series of ifs.
>
> 	Jakub
But even then, you would need a default handler for the remaining cases.

Your walker looks like :

void walk_code (gfc_code *c, void (*handler)(gfc_code *))
{
  if (c == NULL)
    return;

  (*handler) (c);
  walk_code (c->next);
}

your handler like :

void handler (gfc_code *c)
{
  switch (c->op)
    {
    case EXEC_ASSIGN:
      /* Do stuff */
      break;

    case EXEC_CALL:
      /* Do other stuff */
      break;

    default:
      default_handler (c);
      break;
    }
}


and you have a default_handler which is essentially the same as Thomas' 
process_code_node. This is not returning any information and is missing 
the early return that you asked but is it something like this that you 
have in mind ?

About adding state information pointers to the callbacks, I think it can 
be added later if needed.
About the way to say that subtrees shouldn't be traversed, I think that 
a different non-recursive default handler could do the same, so it is 
not necessary (for now at least).

Mikael