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: [PATCH] COND_EXPRs in GIMPLE code and vectorizer

a) if anyone propagates a value anywhere, she should check whether the propagated value is part of a comparison in a COND_EXPR (and explicitly fold the comparison, if so).
b) in case of a COND_EXPR, fold_ternary (...) in fold-const.c folds the comparison before doing anything else (currently, it doesn't do it at all).

I'd go for the second alternative.
It needs an amendment in your statement "fold and friends don't recurse on trees..." for the special case of the comparison of a COND_EXPR, but it avoids explicit checks and folding every time a pass propagates anything into a COND_EXPR.
I think this emphasizes a problem with COND_EXPRs in GIMPLE (and VEC_COND_EXPRs too for that matter; this poor aspect of the design has been there forever): that in this case you cannot assume anymore the RHS of a MODIFY_EXPR to be flat (the other case in which this does not hold is load and stores).

I'd go for the first alternative, writing a fold_gimple_cond_expr function that folds the comparison like this:

static tree
fold_gimple_cond_expr (tree temp)
 tree temp = fold (COND_EXPR_COND (cond_expr));
 if (temp == COND_EXPR_COND (cond_expr))
   return fold (cond_expr);
   return fold_build3 (COND_EXPR, TREE_TYPE (cond_expr), temp,
         COND_EXPR_THEN (cond_expr), COND_EXPR_ELSE (cond_expr));

which can be used in fold_stmt. Roger will surely have more to say, however.

(Remember that fold and friends are not GIMPLE-only. They are used also by front-ends.)


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