Re: [AST-optimizer-branch] Double chaining statements (proposal)

[Diego Novillo <dnovillo at redhat dot com>]

On Tue, 23 Apr 2002, Sebastian Pop wrote:

> On Tue, Apr 23, 2002 at 10:29:36AM -0400, Diego Novillo wrote:
> > On Mon, 22 Apr 2002, Sebastian Pop wrote:
> > 
> > > I just inserted the entry point 'store_prev_stmt' unconditionally 
> > > in order to make it executed without options. 
> > > 
> > Hmm, but this patch is incomplete.  You're just setting
> > TREE_PREV.  You also need to go through the rest of the compiler
> > and update TREE_PREV every time two statements are chained
> > together.
> >
> Not really since what I need this information locally 
> and keep it up to date only during some optimisations,
> then during other passes we can set the 'prev' information to the value 
> it had before : NULL_TREE.
> 
Oh.  Now I think I understand your intent.  You just want to have
TREE_PREV() valid while doing the goto elimination pass?

In that case, maybe we should probably not advertise to the rest
of the compiler that there exists a TREE_PREV?  What about doing
all this inside the goto elimination pass?  If we are not going
to maintain TREE_PREV valid everywhere, we might as well
encapsulate it there.

The idea is to (1) build TREE_PREV,  (2) run goto elimination,
(3) clear TREE_PREV.  All in the same file.


> The only thing the patch shows is that using the 'type' field, 
> on some specific tree nodes (statements), doesn't modify the behaviour 
> of the compiler.
> 
I never doubted that.  Re-using the 'type' field is certainly OK
because statement nodes don't use it.  I just misunderstood what
was the extent of the changes you wanted to make.  I thought that
you wanted to have a globally available TREE_PREV macro that
would always be maintained.

Another thing that I would like to move to is a set of generic
tree manipulation functions to add/remove/modify tree nodes.
We already have a few in tree-cfg.c, but they assume that there
is a flowgraph already.


Diego.