This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch tree-optimization]: Fix for PR 45397 part 2 of 2
On Thu, Mar 15, 2012 at 3:45 PM, Kai Tietz <ktietz70@googlemail.com> wrote:
> 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)
> ...
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