[PATCH] Optimize certain end of loop conditions into min/max operation
Jeff Law
law@redhat.com
Wed Aug 5 16:15:00 GMT 2015
On 08/05/2015 10:07 AM, Alan Lawrence wrote:
> Richard Biener wrote:
>
>> Furthermore it doesn't work for three such ops which would require
>> an additional pattern like
>>
>> (simplfiy
>> (bit_and:c (op @0 (min @1 @2)) (op @0 @3))
>> (op @0 (min (min @1 @2) @3))))
>>
>> if that's profitable?
>
> Shouldn't that be just a case of binding @1 in the original pattern:
>
>>> +/* Transform (@0 < @1 and @0 < @2) to use min */
>>> +(for op (lt le)
>>> +(simplify
>>> +(bit_and:c (op @0 @1) (op @0 @2))
> >> +(if (INTEGRAL_TYPE_P (TREE_TYPE (@0)))
> >> +(op @0 (min @1 @2)))))
>
> to (min @1 @2) in your three-way pattern, @2 in the original to @3 in
> yours, and @0 to @0 ?
>
> Or is @1 not allowed to bind to a 'min' ?
>
>
> Secondly: should/can Michael's fix reference PR57600 ?
It probably should.
Reading that BZ ISTM that we probably are missing some expression
equivalences in DOM. Given
x = min (a, b)
We should be recording
x <= a -> true
x <= b -> true
in our expression equivalency tables (plus all the related
equivalences). I'm not sure if that's the cause of the missed
optimizations or not though. Just something I noticed while reading the BZ.
jeff
More information about the Gcc-patches
mailing list