[PATCH] Some further match.pd optimizations with nop_convert (PR tree-optimization/92734)

[Richard Biener]

On December 5, 2019 2:03:24 PM GMT+01:00, Marc Glisse <marc.glisse@inria.fr> wrote:
>On Wed, 4 Dec 2019, Jakub Jelinek wrote:
>
>> --- gcc/match.pd.jj	2019-12-03 10:20:00.244913801 +0100
>> +++ gcc/match.pd	2019-12-03 13:36:01.084435697 +0100
>> @@ -2159,20 +2159,26 @@ (define_operator_list COND_TERNARY
>>   /* A - (A +- B)       -> -+ B */
>>   /* A +- (B -+ A)      ->  +- B */
>>   (simplify
>> -    (minus (plus:c @0 @1) @0)
>> -    @1)
>> +   (minus (nop_convert (plus:c (nop_convert @0) @1)) @0)
>> +   (view_convert @1))
>
>I know I introduced nop_convert, and it can be convenient, but IIRC it
>also has some limitations.
>
>int f(int b,unsigned c){
>   int a=c;
>   int d=a+b;
>   return d-a;
>}
>int g(int a, int b){
>   int d=(unsigned)a+b;
>   return d-a;
>}
>int h(int b,int a){
>   int d=a+b;
>   return d-a;
>}
>
>While g and h are properly optimized during forwprop1, f isn't, because
>
>nop_convert sees that 'a' comes from a conversion, and only returns d 
>(unlike 'convert?' which would try both a and d).
>
>When inside nop_convert we have an operation, say (nop_convert (plus
>...)), there is no ambiguity, so we are fine. With just (nop_convert
>@0), 
>less so.
>
>It happens that during EVRP, for some reason (different valuization 
>function?), nop_convert does not match the conversion, and we do
>optimize 
>f. But that almost looks like an accident.
>
>convert? with explicit checks would probably work better for the inner 
>conversion, except that handling the vector view_convert case may
>become 
>painful. I didn't think too hard about possible fancy tricks like a
>second 
>nop_convert:
>
>(minus (nop_convert (plus:c (nop_convert @0) @1)) (nop_convert @0))

If use gets more and more we can make nop_convert a first class citizen and allow a? Variant. Or handle all predicates as? Variant. 

Richard.