build tree nodes vs expand as you go

build tree nodes vs expand as you go

[Fergus Henderson]

Hi,

I'm working on a new front-end. 

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?

At first glance expanding them directly looks a little simpler,
but I'm worried I may be missing something...

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

Re: build tree nodes vs expand as you go

[Joern Rennecke]

> What are the trade-offs here?
> 
> At first glance expanding them directly looks a little simpler,
> but I'm worried I may be missing something...

If you don't emit trees, you won't be able to use tree-based optimizations.
OTOH, you save some memory during compile time.

Re: build tree nodes vs expand as you go

[Richard Henderson]

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.


r~

Re: build tree nodes vs expand as you go

[Fergus Henderson]

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.

Re: build tree nodes vs expand as you go

[Richard Henderson]

On Wed, Jan 17, 2001 at 10:42:18PM +1100, Fergus Henderson wrote:
> One of them is that the long term vision doesn't seem to fit with the
> current way of handling switches.

Unfortunately we don't have that language-independant tree
representation for statements yet.  We have two very different
language specific tree representations for those.

> I think I would prefer to wait until there is a language
> independent representation that I can compile to before I go this route.

Fine.  It doesn't sound like it'd take you much to change
when we have a complete interface ready for you to use.


r~