This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Language-independent functions-as-trees representation
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: Jason Merrill <jason at redhat dot com>, <gcc at gcc dot gnu dot org>
- Date: Fri, 23 Aug 2002 18:42:14 -0400 (EDT)
- Subject: Re: Language-independent functions-as-trees representation
- Reply-to: dberlin at dberlin dot org
>
> > 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.
>
>