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: Pop Sébastian <pop at gauvain dot u-strasbg dot fr>
- Cc: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>, 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>, Jan Hubicka <jh at suse dot cz>
- Date: 02 Aug 2003 22:38:27 -0400
- Subject: Re: [tree-ssa] Syntactic structures
- Organization: Red Hat Canada
- References: <20030530183552.GA27110@atrey.karlin.mff.cuni.cz> <firstname.lastname@example.org> <20030727224601.GA5476@atrey.karlin.mff.cuni.cz> <email@example.com> <firstname.lastname@example.org> <4BD7851C-C1EF-11D7-B94D-000A95A34564@dberlin.org> <20030729184217.GA6057@atrey.karlin.mff.cuni.cz> <email@example.com> <20030802233113.GA13635@atrey.karlin.mff.cuni.cz> <firstname.lastname@example.org> <20030803014340.GB21339@gauvain.u-strasbg.fr>
On Sat, 2003-08-02 at 21:43, Pop Sébastian wrote:
> With the current status of things one should keep two representations,
> the cfg and the syntax tree, synchronized. A modification in one
> representation have to update the other representation. This is redundant.
Right. This is what I was referring to when I mentioned performance.
IMO, the duality of the data structures needs to disappear. A single
data structure (the CFG) physically containing sequences of tree or RTL
statements is what I would like us to move to.
In the meantime, we built an API for the tree optimizers to operate on
the underlying trees and provide a CFG + statement sequences data
structure. All the tree optimizers use the flowgraph, the statement
iterators and the operand arrays as their central representation.
Granted, this is C and some of the physical aspects of the underlying
tree structure do escape here and there, but for the most part,
optimizers just see the program as a collection of basic blocks with
sequences of statements in them.
The goal has always been to redesign the tree IL to have better physical
properties, but we are taking an evolutionary approach. With the
current setup, that redesign can be done more or less independently of
Several ideas have been proposed about this issue, but to date I don't
think anybody has implemented any of them. Perhaps this would be a good
time to rehash the ideas again and get something going.