This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Great example of why "everything is a tree" sucks
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Steven Bosscher <stevenb dot gcc at gmail dot com>
- Cc: Diego Novillo <dnovillo at google dot com>, Jakub Jelinek <jakub at redhat dot com>, Jeff Law <law at redhat dot com>, GCC <gcc at gcc dot gnu dot org>
- Date: Wed, 13 Nov 2013 12:25:04 +0100
- Subject: Re: Great example of why "everything is a tree" sucks
- Authentication-results: sourceware.org; auth=none
- References: <528288B3 dot 8010109 at redhat dot com> <20131112203509 dot GC27813 at tucnak dot zalov dot cz> <CAD_=9DQRZy92RCJEopO=XHMj9+eDHQ0MW1g__ZaFNNrWQW=QNg at mail dot gmail dot com> <CAFiYyc38jGfAaWwo5OWTxmQnNeP9=f5McGrW_3HCNJotvbBtKQ at mail dot gmail dot com> <CABu31nOpcf1EivKXYy-i4Czm84aSv+hOYhrSPpefzNVTjjNW0Q at mail dot gmail dot com>
On Wed, Nov 13, 2013 at 11:37 AM, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
> On Wed, Nov 13, 2013 at 11:10 AM, Richard Biener wrote:
>> Well, he doesn't even consider that the exact same "tree rant" applies
>> to frontend code.
>
> That's not entirely true, either. Most front ends already use their
> own IL in the parser (only C++ uses 'tree' for everything).
>
> What worries me most, is that we may end up with:
>
> FE-IL => 'tree' => gimple
>
> where 'tree' is just a memory-consuming, complicated intermediate step
> between the front ends and the middle end. I don't think that's the
> interface we want.
True. The above applies to Fortran and Ada, and maybe also to Go
and Java.
But yes, as far as I understand Andrews plan we'd still require
FE-IL => GENERIC => gimple
where GENERIC is 'tree' based and for the C-family frontends
FE-IL is already GENERIC with some added tree codes that
are lowered during GENERICIZATION (well, not entirely true - the
gimplifier is fed not with GENERIC but with GENERIC+ and uses
langhooks to handle the '+' part ... ugh).
> Really the best place to start IMHO would be to evict 'tree' from the
> front ends. That would really be a step towards making the front ends
> independent of the rest of the compiler, and it would simplify changes
> towards static 'tree' types.
Right. The question is what we'd like the end result to look like?
FE-IL => GIMPLE
I suppose. That means "gimplification" will be the frontends job.
The current hand-off point for IL - cgraph_finalize_function - would
get a function with GIMPLE IL already. It would be reasonably
easy to support both - GENERIC and GIMPLE IL at this point
but I'm not sure how difficult converting a frontend to have its
own "gimplifier" would be. If anybody is eager to try I'd try on
Fortran ;)
Note that this would somewhat break the fact that now frontends
see all of the TUs IL before gimplification starts, so we could also
get the GIMPLE IL at finalize_compilation_unit time, making
"gimplification" a langhook that gets us at the IL.
Eric, would emitting GIMPLE from gigi make that a lot more
complicated? That is, would you prefer to have an even
higher-level early GIMPLE (considering stuff like TARGET_EXPR
and WITH_CLEANUP_EXPR, etc.)?
Richard.
> Ciao!
> Steven