This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] COND_EXPRs in GIMPLE code and vectorizer
- From: Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>
- To: Roberto COSTA <roberto dot costa at st dot com>
- Cc: Roger Sayle <roger at eyesopen dot com>, Daniel Berlin <dberlin at dberlin dot org>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 18 Oct 2006 13:29:09 +0200
- Subject: Re: [PATCH] COND_EXPRs in GIMPLE code and vectorizer
- References: <Pine.LNX.firstname.lastname@example.org> <email@example.com>
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).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).
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'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,
(Remember that fold and friends are not GIMPLE-only. They are used also