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: Language-independent functions-as-trees representation


> 
> > rth has raised some questions about the advisability of using COMPOUND_EXPR
> > to chain statements; the current scheme uses TREE_CHAIN of the statements
> > themselves.  To me, the benefit is modularity; apart from the earlier
> > complaints about the STMT/EXPR distinction, using COMPOUND_EXPR makes it
> > easy to replace a single complex expression with a sequence of simple ones,
> > simply by plugging in a COMPOUND_EXPR in its place.  The current scheme
> > requires a lot more pointer management in order to splice the new STMTs in
> > at both ends.
> > 
> From an optimizer perspective, all you really want is be able to
> traverse all the statements in a basic block using a single
> traversal.

Depends on if we are talking SSA optimizers or not.
Non-SSA optimizers (if we are going to have any) need to be able to do 
this.
SSA optimizers only care about being able to traverse the various chains, 
not the statements themselves.
>  The current scheme of having COMPOUND_STMT (or _EXPR)
> start a new chain is pretty convenient for building the
> flowgraph.  It lets you keep the nesting information in the
> flowgraph itself (basic blocks know exactly which block starts
> the scope they belong to without having to compute dominance
> info).

> 
> Another thing I'd like to have in each statement is the concept
> of parent statement.  This is a pointer to the immediately
> enclosing control statement.  We currently gather this
> information while building the CFG, so if it's too difficult to
> gather while parsing, we could fill it out while building the
> CFG.
This would be nice, as it would solve the complex insertion problems, 
likely.

> I'm all for experimenting with these IL changes, but I would
> first want to have something like SSA-CCP working so that any
> IL changes that break SSA are immediately detected with a
> bootstrap/c-torture failure.

SSA-PRE is also *very* sensitive to IR changes. 
But i'm working on pointer analysis usability before i get back to it, in 
the hopes that the magic SSA fairies will take care of problems inserting 
into various types of statements (since that's why it's not bootstrappable 
with it on right now)
 > > 
> Diego.
> 
> 


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