Re: [PATCH]: Improved handling of COND_EXPR in middle-end passes

[Diego Novillo <dnovillo at redhat dot com>]

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.


> 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.