[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