Re: build tree nodes vs expand as you go

[Fergus Henderson <fjh at cs dot mu dot oz dot au>]

On 22-Dec-2000, Richard Henderson <rth@redhat.com> wrote:
> On Thu, Dec 21, 2000 at 07:21:59PM +1100, Fergus Henderson wrote:
> > I'm trying to decide whether to build a gcc tree node for each
> > statement in my source language (like e.g. the Java front-end does),
> > or whether to just expand them directly, using expand_start_cond(),
> > expand_else(), expand_end_cond() etc.
> > 
> > What are the trade-offs here?
> 
> The long term vision is that a front end doesn't deal with rtl at all, but
> instead hands off a tree describing the entire function to the middle end.
> 
> At which point we do tree-based optimizations, then convert to an oft
> wished for mid-level rtl (more regular and less machine specific) and do
> SSA based optimizations, then convert to the rtl used today.
> 
> So please do generate trees for the entire function.

Thanks for the quick reply.

Unfortunately it wasn't quite quick enough; by the time I received it,
I'd already gone ahead implemented things the other way :-(.
I did it the other way because that I found that way to be easier.
However, there's not very much code in the Mercury front-end which
depends on it, so in theory should be reasonably easy for me to convert
it to generate trees for the entire function.

In attempting to do so, I have however come across some tricky issues.
One of them is that the long term vision doesn't seem to fit with the
current way of handling switches.  Currently the representation of the
case values in a SWITCH_EXPR is "front-end implementation defined".
How are the tree-based optimizations going to handle that?

The C and C++ front-ends don't use SWITCH_EXPR at all.
The C++ builds a tree for the entire function, but this
tree contains a large number of language-specific tree nodes.
For switches, C++ uses language-specific SWITCH_STMT and CASE_LABEL
nodes.  These never get converted into a language-independent tree
representation; instead they get converted directly from this
language-specific representation into RTL.  How are the tree-based
optimizations going to handle language-specific tree nodes?

Compiling to a language-dependent tree representation doesn't
seem to be much of an improvement over converting directly
to RTL, and is definitely more complicated.  I think I would
prefer to wait until there is a language independent representation
that I can compile to before I go this route.

I'm happy to follow the path set by other GCC developers.
However, I would rather not be the one to blaze the trail ;-)

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.