Re: Language-independent functions-as-trees representation

[Jason Merrill <jason at redhat dot com>]

On Fri, 23 Aug 2002 15:16:21 -0400, Diego Novillo <dnovillo@redhat.com> wrote:

> On Fri, 23 Aug 2002, Jason Merrill wrote:

>> It seems to me that double-chaining could be provided by using the
>> TREE_CHAIN of the COMPOUND_EXPRs.
>> 
> How so?  I'm afraid I'm not following you here.

TREE_CHAIN of a COMPOUND_EXPR is currently unused; a sequence of statements
is represented by a series of COMPOUND_EXPRs, each with a statement in op0,
pointing to the next one through op1.

>>    loop-stmt:
>>      LOOP_EXPR
>>        LOOP_EXPR_BODY -> stmt | NULL_TREE
>>      | DO_LOOP_EXPR
>>        (to be defined later)

> I would prefer to have 2 generic loop expressions and 1 Fortran
> do-loop expression.  The two generic loops would be for
> do-while and while constructs.  However, we could get by with
> just a do-while guarded with an if() (a-la SUIF).

The Java frontend uses a LOOP_EXPR (infinite loop) with an EXIT_EXPR for
the loop condition, either at the beginning or end of the statement chain
in LOOP_EXPR_BODY, for while and do-while loops respectively.  Does this
work for you, or is that a significant inconvenience compared to hanging
the condition directly off of the loop node?

The key benefit of this scheme for SIMPLE is that it allows us to simplify
the loop condition without having to copy its preque around a la
insert_before_continue.  If the condition needs simplification, we just end
up with a few other statements before we get to the EXIT_EXPR.

> For the
> do-loop expression,  I'd like:
>
> 	DO_LOOP_EXPR
> 		INDEX_DECL -> var
> 		LB_EXPR -> val
> 		UB_EXPR -> val
> 		COND_CODE -> '<' | '>' | '<=' | '>='
> 		STEP_EXPR -> val
> 		LANDING_EXPR -> COMPOUND_EXPR
> 		BODY_EXPR -> COMPOUND_EXPR

I would say -> stmt for the last two.

> LANDING_EXPR is just a convenience for optimizers to have somewhere to
> blindly move invariant code to.  We could do without it.

I think my preference would be to do without it; if we're moving code out
of the loop, it should go out of the loop.  But I don't feel strongly about
this.

>> From an optimization perspective, are LABELED_BLOCK_EXPR/EXIT_BLOCK_EXPR
>> easier to deal with than plain gotos?  I assume they're preferable to
>> the current loosely bound BREAK_STMT, which has no information about
>> what it's exiting.  EXIT_EXPR would have the same problem if it were
>> used to express 'break'.

> What's wrong with BREAK_STMT?  As long as you know its parent,
> it's relatively easy to figure out where to send the flow edge.
> GOTO_STMTs are just as easy to deal with.  I don't have a problem
> with the existing setup.  I don't know about
> LABELED_BLOCK_EXPR/EXIT_BLOCK_EXPR.

My thinking was that if you're walking through a function the first time,
when you see an EXIT_BLOCK_EXPR you know exactly which blocks it is going
to close, and thus what cleanups and whatnot you might need to do.  With a
general goto, if you haven't seen the label yet you don't know much of
anything.  I suppose that in the optimizer you can annotate the gotos
appropriately, but it's a bit more complicated.

The thing about BREAK_STMT is that expand_exit_something has variable
semantics; the things it does or doesn't exit depend on the value of
exit_flag passed to expand_start_loop et al.  I'd prefer to make what it
exits explicit.

>> I've attached my current patch below; it's still in the toy stages, but
>> gives an idea of my implementation strategy.
>> 
> Note that any changes you make to the tree representation are
> very likely to break the CFG and SSA builders.  We want to
> experiment, but we also need to make sure that any changes we
> make to the IL are reflected in the CFG and dataflow info.

Indeed; that's why I was asking for people interested in helping to adjust
the various optimizers.

Jason