[PATCH] match.pd: Canonicalize (X + (X >> (prec - 1))) ^ (X >> (prec - 1)) to abs (X) [PR94783]

[Jeff Law]

On Thu, 2020-05-07 at 10:12 +0200, Richard Biener wrote:
> On Thu, 7 May 2020, Jakub Jelinek wrote:
> 
> > Hi!
> > 
> > The following patch canonicalizes M = X >> (prec - 1); (X + M) ^ M
> > for signed integral types into ABS_EXPR (X).  For X == min it is already
> > UB because M is -1 and min + -1 is UB, so we can use ABS_EXPR rather than
> > say ABSU_EXPR + cast.
> > 
> > The backend might then emit the abs code back using the shift and addition
> > and xor if it is the best sequence for the target, but could do something
> > different that is better.
> > 
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> > 
> > 2020-05-06  Jakub Jelinek  <jakub@redhat.com>
> > 
> > 	PR tree-optimization/94783
> > 	* match.pd ((X + (X >> (prec - 1))) ^ (X >> (prec - 1)) to abs (X)):
> > 	New simplification.
> > 
> > 	* gcc.dg/tree-ssa/pr94783.c: New test.
> > 
> > --- gcc/match.pd.jj	2020-05-06 15:48:23.658858289 +0200
> > +++ gcc/match.pd	2020-05-06 17:47:02.035347946 +0200
> > @@ -120,6 +120,18 @@ (define_operator_list COND_TERNARY
> >    (with { tree utype = unsigned_type_for (TREE_TYPE (@0)); }
> >     (convert (absu:utype @0)))))
> >  
> > +#if GIMPLE
> > +/* Optimize (X + (X >> (prec - 1))) ^ (X >> (prec - 1)) into abs (X).  */
> > +(simplify
> > + (bit_xor:c (plus:cs @0 (rshift@2 @0 INTEGER_CST@1)) @2)
> > + (if (ANY_INTEGRAL_TYPE_P (TREE_TYPE (@0))
> > +      && !TYPE_UNSIGNED (TREE_TYPE (@0))
> > +      && TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0))
> > +      && wi::to_widest (@1) == element_precision (TREE_TYPE (@0)) - 1
> > +      && TREE_CODE (@2) == SSA_NAME
> > +      && num_imm_uses (@2) == 2)
> 
> I fear this num_imm_uses test is quite fragile since match.pd patterns
> are invoked on transient sequences (w/o SSA operands) as well
> (that of course holds for all single_use () tests as well but that
> at least allows zero uses for this very reason - still fragile since
> the single use might be _in_ the IL and thus a second).
> 
> I think unconditionally using (abs @0) is simplifying things enough
> (getting rid of one xor and one plus) to not worry about keeping
> the (x >> (prec - 1))?
I'd tend to agree.   abs form is optimized better all the way to code generation,
so there's probably good secondary benefits as well.

jeff
>