This is the mail archive of the
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 <firstname.lastname@example.org> 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
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
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.)?