Re: Language-independent functions-as-trees representation

[Richard Henderson <rth at redhat dot com>]

On Fri, Aug 23, 2002 at 03:16:21PM -0400, Diego Novillo wrote:
> 	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
> 
> This is equivalent to the following:
> 
> for (INDEX_DECL = LB_EXPR;
>      INDEX_DECL COND_CODE UB_EXPR;
>      INDEX_DECL += STEP_EXPR)
> {
>   if (INDEX_DECL == LB_EXPR)
>     LANDING_EXPR;
>   else
>     BODY_EXPR;
> }
>
> LANDING_EXPR is just a convenience for optimizers to have
> somewhere to blindly move invariant code to.  This would be
> expanded to something like:
> 
> INDEX_DECL = LB_EXPR;
> if (INDEX_DECL COND_CODE UB_EXPR)
>     LANDING_EXPR;
> for (...)

Surely a better expansion is

	INDEX_DECL = LB_EXPR;
	if (INDEX_DECL COND_CODE UB_EXPR)
	  {
	    LANDING_EXPR;
	    do {
	      BODY_EXPR;
	      INDEX_DECL += STEP_EXPR;
	    } while (INDEX_DECL COND_CODE UB_EXPR);
	  }

And, really, I'm sort of with Jason in wondering whether the
LANDING_EXPR is really useful at this stage.

> Another important feature of DO_LOOP_EXPR is that both UB_EXPR and
> STEP_EXPR should be loop invariant (ideally, constants).

We have two choices here: either require the front end to 
know that these are loop-invariant beforehand (either by
dataflow analysis or by the undefined-ness of the source
program that would have created such nodes), or we can
copy these expressions into temporaries ourselves.  I.e.

	T.lb = LB_EXPR;
	T.ub = UB_EXPR;
	INDEX_DECL = T.lb;
	if (INDEX_DECL COND_CODE T.ub)
	  ...

> What's wrong with BREAK_STMT?  As long as you know its parent,

That's the point, really.  Not having to track the parent
after the fact.


r~