This is the mail archive of the
mailing list for the GCC project.
Re: Language-independent functions-as-trees representation
On Fri, Aug 23, 2002 at 03:16:21PM -0400, Diego Novillo wrote:
> 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 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)
> for (...)
Surely a better expansion is
INDEX_DECL = LB_EXPR;
if (INDEX_DECL COND_CODE UB_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.