Re: [tree-ssa] Syntactic structures

[Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>]

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".

they do things that are unnecessary.  IMO it would be better if at the
beginning the proposed reorganization was done, than to write a quick
hack that is then fought in a complicated way (I don't know how else
would you want to call 5000 lines of tree-cfg.c).

> It's much nicer than the morass that are RTL iterators.

What do you mean by this?

> >>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

No we don't.

Zdenek