Re: [tree-ssa] Syntactic structures

[Daniel Berlin <dberlin at dberlin dot org>]

On Sunday, August 3, 2003, at 12:37 PM, Zdenek Dvorak wrote:

> Hello,
>
> > > 1) are there some optimizations on tree-ssa that benefit from keeping
> > >    all the syntactical structures around.
> > >    , instead of just cfg + chain
> > The optimizers only see the CFG and a sequence of statements inside 
> > each
> > basic block.  It is true that internally, the statements are organized
> > in a tree-like structure.  That is something that we would eventually
> > want to change, purely for performance reasons.
> >
> > For all intents and purposes, the optimizers are presented a linear
> > sequence of statements contained inside basic blocks.  Have you looked
> > at the statement iterators?
>
> yes.  They are ugly. I would also say they are slow, but this is of
> course just my feeling.

Say what?
How are they "ugly".
It's much nicer than the morass that are RTL iterators.

> > This is how you traverse all the statements in the program:
> >
> > FOR_EACH_BB(bb)
> >   for (si = bsi_start (bb); !bsi_end_p (si); bsi_next (&si))
> >      tree stmt = bsi_stmt (si);
> >
> > If you want to traverse in dominator tree order, you simply start a
> > recursive walk at ENTRY_BLOCK_PTR much like tree-ssa.c and
> > tree-ssa-dom.c do.
> >
> > Statement insertion and removal are also supported (both on edges and 
> > in
> > blocks).
> >
> > There are some missing functions in the iterator API, so whatever you
> > find missing, we would like to know.
>
> What I tried is to create (well, actually debug Sebastian's one) a
> split_block function.  It still does not work, although perhaps with a
> day more I could succeed.

We already have one in tree-cfg.c

> > > I am mostly decided to postpone the loop optimizer work a bit and
> > > instead clean up this mess.  Would someone mind?
> > You will have to be more specific.  The word 'mess' is colorful but
> > hardly descriptive.  What is it that you are trying to do?  How is it
> > not working?  What do you think is missing?  Loop optimization will
> > likely expose limitations in the current framework, but we need more
> > specific information to address the problems.
>
> I would like to get rid of the "invisible" part of the tree structures
> (COMPOUND_EXPR, BIND_EXPR, LOOP_EXPR and such).

> Zdenek