Re: treelang fix for rs6000 / treelang not proper front end

[Steven Bosscher <s dot bosscher at student dot tudelft dot nl>]

Tim Josling wrote:

> Steven Bosscher wrote:
>
> > So, what do we _want_ to show with treelang?  What is the function of 
> > treelang within GCC and what implications does that have for its design?
> >
> > Gr.
> > Steven
>
>
> The purpose is to make it easier for people to write front ends.
>
> If building trees is the best way to write front ends, it should do that.
>
> I don't fully understand what you are saying, but I think there are 
> two questions. 

Yeah my mails usually are too long :-)

> 1. Should you build trees which are then converted into rtl a function 
> at a time. I think the answer here is you should use function at a 
> time - i.e. build trees, not, go directly to rtl as treelang does now. 
> However I have no experience with FAAT so I am really taking your word 
> for it. 


All new front ends should build whole functions as trees.  Those trees 
are then optimized (currently the only tree optimizer is the inliner, 
but that is what tree-ssa is all about) and expanded to RTL, eventually 
by a shared expander, so the front end only hands off function trees.

The front ends that do not build functions as trees right now are:
- G77, which is obsolete.  Nobody has shown interest in even trying to 
make it build functions as trees AFAIK.  Scheduled for removal once G95 
has proven itself.
- Ada, for which work to make it build functions as trees has been 
announced a few times (but nothing so far, fingers crossed... ;-)
- Treelang...

I have to admit here that even in GCC 3.4 the only non-C front end that 
uses the tree inliner has to hack its way around the C bias in 
tree-inline.c.  But on the tree-ssa branch, the tree inliner inlines is 
part of the language independent optimization framework.

Maybe we should keep things as-is for 3.4 and go proper for 3.5 (when 
tree-ssa will be merger).

> 2. Should the front end have its own language-specific tree 
> representation which is then later converted into gcc-specific things 
> (eg trees or rtl)?
>
> This depends on the context. For example, one may want to generate C 
> out of the compiler, sometimes, instead of front ending GCC back end. 
> In this case, you really need your own representation. Having your own 
> representation also increases the isolation of the front end from the 
> innards of GCC. With the COBOL compiler I have found this to be a very 
> good thing. 


I agree that having your own representation certainly can have 
advantages, such as ease of porting to other back ends or for 
source-to-source translators (C-like unparsing is also in the tree-ssa 
branch BTW), or when you're developing a front end for a rather 
complicated language (which is why G95 has its own representation).   
But if an example front end should only clarify the "GCC front-end 
interface", then there's really no reason to give it its own 
representation.  I believe that is the context treelang should be in: 
keep it simple and make it easy to understand the essentials of the 
front-end interface, hence 'tree' only.

But as you correctly pointed out in your first mail, someone will have 
to try first.  I'll see if I can come up with an example of what it 
would look likein the next few weeks.  In the mean time, I'll apply my 
update of Ferfus's patch to tree-ssa if that's OK with Diego, and post a 
patch for mainline as well.  I'm sure it will not be so hard to clean it 
up a bit more and maintain it until 3.4 is out.  Does that sound like a 
reasonable plan?

Gr.
Steven