Re: [patch tree-optimization]: Fix for PR 45397 part 2 of 2

[Kai Tietz <ktietz70@googlemail.com>]

2012/3/15 Richard Guenther <richard.guenther@gmail.com>:
> On Thu, Mar 15, 2012 at 2:46 PM, Kai Tietz <ktietz70@googlemail.com> wrote:
>> 2012/3/15 Richard Guenther <richard.guenther@gmail.com>:
>>> On Thu, Mar 15, 2012 at 2:09 PM, Kai Tietz <ktietz70@googlemail.com> wrote:
>>>> Hi,
>>>>
>>>> this is the second part of the patch for this problem.  It adds some
>>>> basic simplifications for ==/!=
>>>> comparisons for eliminating redudant operands.
>>>>
>>>> It adds the following patterns:
>>>>  -X ==/!= Z - X -> Z ==/!= 0.
>>>>  ~X ==/!= Z ^ X -> Z ==/!= ~0
>>>>  X ==/!= X - Y -> Y == 0
>>>>  X ==/!= X + Y -> Y == 0
>>>>  X ==/!= X ^ Y -> Y == 0
>>>>  (X - Y) ==/!= (Z - Y) -> X ==/!= Z
>>>>  (Y - X) ==/!= (Y - Z) -> X ==/!= Z
>>>>  (X + Y) ==/!= (X + Z) -> Y ==/!= Z
>>>>  (X + Y) ==/!= (Z + X) -> Y ==/!= Z
>>>>  (X ^ Y) ==/!= (Z ^ X) -> Y ==/!= Z
>>>
>>> Can you re-base this patch to work without the previous one?  Also
>>> please coordinate with Andrew.  Note that all of these(?) simplifications
>>> are already done by fold_comparison which we could share if you'd split
>>> out the EXPR_P op0/op1 cases with separated operands/code.
>>>
>>> Richard.
>>
>> Hmm, fold_comparison doesn't do the same thing as it checks for
>> possible overflow.  This is true for comparisons not being ==/!= or
>> having operands of none-integral-type.  But for ==/!= with integral
>> typed arguments  the overflow doesn't matter at all.  And exactly this
>> is what patch implements here.
>
> fold_comparison does not check for overflow for ==/!=.
>
>> This optimization of course is just desired in non-AST form, as we
>> otherwise loose information in FE.  Therefore I didn't added it to
>> fold_const.
>
> Which pieces are not already in fold-const btw?  forwprop already
> re-constructs trees for the defs of the lhs/rhs of a comparison.
>
> Richard.

I have tried to use here instead a call to fold_build2 instead, and I
had to notice that it didn't optimized a single case (beside the - and
~ case on both sides).

I see in fold const for example in the pattern 'X +- C1 CMP Y +- C2'
to 'X CMP Y +- C2 +- C1' explicit the check for it.

...
/* Transform comparisons of the form X +- C1 CMP Y +- C2 to
   X CMP Y +- C2 +- C1 for signed X, Y.  This is valid if
   the resulting offset is smaller in absolute value than the
   original one.  */
if (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (arg0))
    && (TREE_CODE (arg0) == PLUS_EXPR || TREE_CODE (arg0) == MINUS_EXPR)
...

The same for pattern X +- C1 CMP C2 to X CMP C2 +- C1.

The cases for '(X + Y) ==/!= (Z + X)' and co have the same issue or
are simply not present.

Sorry fold_const doesn't cover this at all.

Kai