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

[Jan Hubicka <jh at suse dot cz>]

> On Mon, 15 Apr 2002, Sebastian Pop wrote:
> 
> > Hi,
> > 
> > C and C++ statements don't use 'type' field : this field is used only 
> > in expression nodes.
> > 
> > struct tree_common
> > {
> >   tree chain;
> >   tree type;
> >   void *aux;
> > ...
> > }
> > 
> > We could use it to hold information about the previous statement
> > and make analysis and transformation of statements simpler.
> > 
> > I propose to complete the tree interface with the following macro :
> > #define TREE_PREV(STMT) TREE_TYPE (STMT)
> > and either modify front-ends, or introduce this information during 
> > the simplify pass.
> > 
> > Comments, suggestions, ... ?
> > 
> At times I have wished I had a TREE_PREV() link, but I am not
> absolutely convinced that it is a requirement.  We have several
> options:
> 
> - Overloading an existing field.  This saves memory but abuses
>   the name space.  We already have much name abusing in the tree
>   structure.
> 
> - Creating a 'prev' field in tree_node.  IMO the cleanest
>   approach, but increases memory usage.
> 
> - Do nothing.  Every pass that needs to keep TREE_PREV pointers
>   should save 'prev' while traversing, and/or use the CFG to find
>   predecessors.  The second option is what we use once we have
>   the CFG.
> 
> We need to find a balance between implementation complexity and
> compilation time.  No doubt that having TREE_PREV will help some
> traversals, particularly those that are done before the CFG is
> built.
> 
> However, the presence of TREE_PREV means that we have to go
> through every line of code that manipulates trees and make sure
> that every time we chain two tree statements, the TREE_PREV field
> of the second statement is updated properly.

SHould not the tree code use something generic to add/remove statement
from the chain anyway, like RTL based optimizer does?

Honza
> 
> 
> Diego.