This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] Syntactic structures
- From: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- To: Diego Novillo <dnovillo at redhat dot com>
- 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: Sun, 3 Aug 2003 18:37:05 +0200
- Subject: Re: [tree-ssa] Syntactic structures
- 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> <email@example.com>
> > 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 (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
> 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).