2012/3/21 Richard Guenther <richard.guent...@gmail.com>:
> On Thu, Mar 15, 2012 at 3:45 PM, Kai Tietz <ktiet...@googlemail.com> wrote:
>> 2012/3/15 Richard Guenther <richard.guent...@gmail.com>:
>>> On Thu, Mar 15, 2012 at 2:46 PM, Kai Tietz <ktiet...@googlemail.com> wrote:
>>>> 2012/3/15 Richard Guenther <richard.guent...@gmail.com>:
>>>>> On Thu, Mar 15, 2012 at 2:09 PM, Kai Tietz <ktiet...@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)
>> ...
>
> Because the transform is not valid if Y +- C2 +- C1 overflows. It is not
> valid
> because overflow is undefined, not because the comparison would do the
> wrong thing. You'd have to change the addition to unsigned.
>
>> The same for pattern X +- C1 CMP C2 to X CMP C2 +- C1.
>
> Well, this is obviously just a missed optimization in fold-const.c then. Mind
> conditionalizing the overflow check to codes not NE_EXPR or EQ_EXPR?
>
>> The cases for '(X + Y) ==/!= (Z + X)' and co have the same issue or
>> are simply not present.
>
> That's true. I suppose they were considered too special to worry about.
> Did you see these cases in real code?
>
>> Sorry fold_const doesn't cover this at all.
>
> It covers part of it.
>
>> Kai
Sure, the test code shown in this patch isn't that unusual.
Especially in gimple (by using different statements) such construct
are happening.
Eg.:
int f1 (int a, int b, int c)
{
if ((a + b) == (c + a))
return 1;
return 0;
}
int f2 (int a, int b, int c)
{
if ((a ^ b) == (a ^ c))
return 1;
return 0;
}
int f2 (int a, int b)
{
if (-a == (b - a))
return 1;
return 0;
}
In all those cases the use of variable should be optimized out.
Instead we are producing pretty weak code for those cases.
Kai
