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: [tree-ssa] g95 SEGV building libgfortran

On Thursday 04 September 2003 10:13 pm, you wrote:
> In message <>, Diego
> Novillo
> writes:
>  >Aha!  This is where we go back to the language vs optimizer issue :) 
>  > If we don't allow the FE to generate LOOP_EXPR, then we are
>  > effectively changing the GIMPLE grammar.
> Well, given that LOOP_EXPR was taken out of tree-simple.[ch] I think that
> we're going to a model where LOOP_EXPR is not part of the gimple grammar.
> However, it _might_ be part of the generic grammar.  I really don't know
> (I haven't thought too much about that).

Personaly I think it should be part of GENERIC. If nothing else it makes it 
much easier to debug frontends when these things are still explicit.

>  >I'm fine with that, but we need to
>  >document the change in the grammar and probably ask the Fortran folks
>  > if that's OK with them.
> Well, the change in the grammar is already documented in tree-simple.? 
> Are there other instances that need to change?
> Note that we've talked about having a lowering pass (for COND_EXPR,
> SWITCH_EXPR, etc) -- fundamentally if that's where we go, then the
> fortran front-end will need to call into that lowering pass rather
> than assuming the gimplification process will do it.
> If that's where we ultimately go, then lowering the LOOP_EXPR there
> would seem pretty natural, except the the fact that we removed LOOP_EXPR
> from tree-simple.? :-)

I think we need to distinguish between GENERIC and GIMPLE. I would expect 
tree_rest_of_compilation to perform any lowering and/or gimplification that 
is neccessary. Maybe a couple of extra flags specifying what lowering has 
already been performed might be beneficial.

The last definiton of GENERIC that I saw was something like "anything that 
appears in tree.def". This seems a fairly reasonable (if somewhat vague) 
definition to me. If tree codes aren't handled by the l-i backend 
interface, why are they defined in a l-i manner?

>  >I don't know whether it's merely annoying or impossible to make that
>  >change in the Fortran FE.  In principle, I wouldn't think it's
>  >impossible, but then again I'm not the one making the change :)
> It doesn't look terribly difficult to change in the fortran front-end.
> There's probably a half-dozen instances and they share enough common
> structure that they may be factorable into a single routine anyway, so
> it could be isolated.
> Anyway, we need to settle on which way we want to go.  Do we remove
> LOOP_EXPR from the gimple grammar, or do we leave it in gimple, but
> lower them to labels & jumps before building the cfg?

My vote is to leave LOOP_EXPRs in the interface to the frontends (ie 
GENERIC). Otherwise we're going to end up with large amounts of lowering 
code duplicated between the different frontends.

What you do after the frontend has passed the tree over to the optimizers is 
up to you:)


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