Diego Novillo wrote:
Roberto COSTA wrote on 11/27/06 11:31:
The question COND_EXPR as rhs vs explicit control-flow is the very
reason why I started this short investigation about COND_EXPRs in
GIMPLE.
In particular, I was interested in the impact of the two alternatives
for the CLI back-end project.
OK, so it seems like we have quite a few good reasons to keep
supporting COND_EXPRs on the RHS of assignments. The next question is
whether we want to systematically convert every
if (PRED)
VAR = VAL1
else
VAR = VAL2
endif
to
VAR = (PRED) ? VAL1 : VAL2
In principle, I would say that this should be handled by a
canonicalization pass that is called right before the passes that can
benefit from this notation. This gives us the flexibility of not
worrying about keeping VAR = COND_EXPRs all the time, and just build
them when it's more convenient.
And for passes that cannot benefit from the more compact notation,
they certainly should handle them gracefully.
Just back from a very loooong vacation...
Happy new year to everybody!
I agree.
IMHO, flexibility is indeed needed, because of the pros and cons of rhs
COND_EXPRs we have considered so far.
For instance, I would make sense to me to place such a canonicalization
pass after the first dom pass (this means that jump threading is done at
least once, since we know it loses optimization opportunities in the
presence of rhs COND_EXPRs). Perhaps the canonicalization could even
become part of what phiopt already does (this is just an idea, I haven't
thought much about it).
2006-11-22 Roberto Costa <roberto.costa@st.com>
* tree-vrp.c (extract_range_from_cond_expr): New.
(extract_range_from_expr): Handle COND_EXPR nodes used as
expressions.
* tree-ssa-ccp.c (get_maxval_strlen): Handle COND_EXPR nodes used
as expressions.
(fold_stmt): Bug fix, avoid infinite recursion when folding
COND_EXPRs.
* tree-ssa-forwprop.c (simplify_cond, forward_propagate_into_cond,
tree_ssa_forward_propagate_single_use_vars): Handle COND_EXPR nodes
used as expressions.
* tree-object-size.c (cond_expr_object_size): New.
(collect_object_sizes_for): Handle COND_EXPR nodes used as
expressions.
OK. Sorry for having dragged the argument longer than necessary.
No problem.
I'm re-testing the patch, I will commit if everything is ok.