This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] Syntactic structures
- From: Diego Novillo <dnovillo at redhat dot com>
- To: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- Cc: Daniel Berlin <dberlin at dberlin dot org>, Zack Weinberg <zack at codesourcery dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Richard Henderson <rth at redhat dot com>, Jason Merrill <jason at redhat dot com>, pop at gauvain dot u-strasbg dot fr, Jan Hubicka <jh at suse dot cz>
- Date: 02 Aug 2003 19:49:58 -0400
- Subject: Re: [tree-ssa] Syntactic structures
- Organization: Red Hat Canada
- References: <20030530183552.GA27110@atrey.karlin.mff.cuni.cz> <email@example.com> <20030727224601.GA5476@atrey.karlin.mff.cuni.cz> <firstname.lastname@example.org> <email@example.com> <4BD7851C-C1EF-11D7-B94D-000A95A34564@dberlin.org> <20030729184217.GA6057@atrey.karlin.mff.cuni.cz> <firstname.lastname@example.org> <20030802233113.GA13635@atrey.karlin.mff.cuni.cz>
On Sat, 2003-08-02 at 19:31, Zdenek Dvorak wrote:
> 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?
This is how you traverse all the statements in the program:
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
Statement insertion and removal are also supported (both on edges and in
There are some missing functions in the iterator API, so whatever you
find missing, we would like to know.
> 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.