This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH]: Improved handling of COND_EXPR in middle-end passes
- From: Diego Novillo <dnovillo at redhat dot com>
- To: Roberto COSTA <roberto dot costa at st dot com>
- Cc: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>, Roger Sayle <roger at eyesopen dot com>, Ian Lance Taylor <ian at airs dot com>, Andrew MacLeod <amacleod at redhat dot com>, GCC patches mailing list <gcc-patches at gcc dot gnu dot org>, Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>, Dorit Naishlos <DORIT at il dot ibm dot com>
- Date: Sat, 16 Dec 2006 11:02:15 -0500
- Subject: Re: [PATCH]: Improved handling of COND_EXPR in middle-end passes
- References: <email@example.com> <20061122132938.GA3683@atrey.karlin.mff.cuni.cz> <456ABF4D.firstname.lastname@example.org> <456AFD49.email@example.com> <456B12F0.firstname.lastname@example.org>
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.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
In particular, I was interested in the impact of the two alternatives
for the CLI back-end project.
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 <email@example.com>OK. Sorry for having dragged the argument longer than necessary.
* 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
(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.