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]: Improved handling of COND_EXPR in middle-end passes

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
		VAR = VAL2


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

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

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