Re: [PATCH] Optimize certain end of loop conditions into min/max operation

[Jeff Law <law at redhat dot com>]

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