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: [tree-ssa] Syntactic structures


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.

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

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


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