Re: Fix COND_EXPR foldings that are not happening

[Roger Sayle <roger at eyesopen dot com>]

On Sat, 19 Jun 2004, Paolo Bonzini wrote:
> Ok like this?
>
> /* Subroutine of fold, looking inside expressions of the form
>    A op B ? A : C, where ARG0 is A op B and ARG2 is C.  This function
>    is being used also to optimize A op B ? C : A, by reversing the
>    comparison first.
>
>    Return a folded expression whose code is not a COND_EXPR anymore,
>    or NULL_TREE if no folding opportunity is found.  */

Perfect.


> > It looks like you're still removing this optimization, rather than just
> > adding /* A < 0 ? <sign bit of A> : 0 is simply (A & <sign bit of A>).  */
> > and /* (A >> N) & 1 ? (1 << N) : 0 is simply A & (1 << N).  */
>
> Yes, I am because BIT_AND_EXPR's *cannot* be in the first operand of
> COND_EXPRs -- only TRUTH_AND_EXPR's.  The (A & 1 ? 1 : 0) is caught
> elsewhere by the transformation of (X ? 1 : 0) into X, because the & is
> a TRUTH_AND_EXPR.

This may have been a recent change with the tree-ssa merge (anyone?),
but the COND_EXPR tree node is currently documented in c-tree.texi as
"The first operand is of boolean or integral type.  If it evaluates to
a nonzero value...".  Perhaps this is one of the areas where GIMPLE
has stricter requirements than GENERIC.

For the time being I'd recommend leaving it in, under the "if it ain't
broke, don't fix it" rule.  A bit of digging shows this optimization has
been in GCC, almost unchanged, since atleast v2.5.8.


However, you might consider also adding support for

	"(X != 0) ? Y : Z" -> "X ? Y : Z"

and/or

	"((X & C) != 0) ? C : 0" -> "X & C".


Roger
--