This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] COND_EXPRs in GIMPLE code and vectorizer
Paolo Bonzini wrote:
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
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:
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,
If I well understand your proposal, this implies a test in fold_stmt
(...) that checks for MODIFY_EXPRs with a COND_EXPR on the rhs.
In the second alternative, something special is done only in the
presence of COND_EXPRs (I mean, not for every statement).
Ok, perhaps, the difference in efficiency is small and neglectable.
(Remember that fold and friends are not GIMPLE-only. They are used also