This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Great example of why "everything is a tree" sucks

On Wed, Nov 13, 2013 at 11:37 AM, Steven Bosscher <> 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?


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


> Ciao!
> Steven

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]