On Thu, Dec 5, 2019 at 4:16 PM Richard Biener <rguent...@suse.de> wrote:
>
> On December 5, 2019 2:03:24 PM GMT+01:00, Marc Glisse <marc.gli...@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.Like the attached (need to adjust docs & rename some functions still) which generalizes [digit]? parsing. This allows you to write (nop_convert? ...) It works (generated files are unchanged), so I guess I'll push it after polishing. It also extends the 1/2/3 grouping to be able to group like (plus (nop_convert2? @0) (convert2? @1)) so either both will be present or none (meaning that when grouping you can choose the "cheaper" test for one in case you know the conversions will be the same). Richard. > Richard. >
p2
Description: Binary data
