On Thu, Sep 20, 2018 at 4:00 PM Marc Glisse <marc.gli...@inria.fr> wrote:
>
> On Thu, 20 Sep 2018, Richard Biener wrote:
>
> > On Sat, Sep 15, 2018 at 8:01 AM MCC CS <mc...@gmx.com> wrote:
> >>
> >> Sorry for doing the same mistake twice. Is this OK, and do
> >> I need to test it again after the first version of this
> >> patch?
> >>
> >> 2018-09-15 MCC CS <deswurs...@users.noreply.github.com>
> >>
> >> gcc/
> >> PR tree-optimization/87261
> >> * match.pd: Add boolean optimizations,
> >> fix whitespace.
> >>
> >> 2018-09-15 MCC CS <deswurs...@users.noreply.github.com>
> >>
> >> gcc/testsuite/
> >> PR tree-optimization/87261
> >> * gcc.dg/pr87261.c: New test.
> >>
> >> Index: gcc/match.pd
> >> ===================================================================
> >> --- gcc/match.pd (revision 264170)
> >> +++ gcc/match.pd (working copy)
> >> @@ -92,7 +92,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> >> IFN_FMA IFN_FMS IFN_FNMA IFN_FNMS)
> >> (define_operator_list COND_TERNARY
> >> IFN_COND_FMA IFN_COND_FMS IFN_COND_FNMA IFN_COND_FNMS)
> >> -
> >> +
> >> /* As opposed to convert?, this still creates a single pattern, so
> >> it is not a suitable replacement for convert? in all cases. */
> >> (match (nop_convert @0)
> >> @@ -106,7 +106,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> >> && tree_nop_conversion_p (TREE_TYPE (type), TREE_TYPE (TREE_TYPE
> >> (@0))))))
> >> /* This one has to be last, or it shadows the others. */
> >> (match (nop_convert @0)
> >> - @0)
> >> + @0)
> >>
> >> /* Transform likes of (char) ABS_EXPR <(int) x> into (char) ABSU_EXPR <x>
> >> ABSU_EXPR returns unsigned absolute value of the operand and the
> >> operand
> >> @@ -285,7 +285,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> >> And not for _Fract types where we can't build 1. */
> >> (if (!integer_zerop (@0) && !ALL_FRACT_MODE_P (TYPE_MODE (type)))
> >> { build_one_cst (type); }))
> >> - /* X / abs (X) is X < 0 ? -1 : 1. */
> >> + /* X / abs (X) is X < 0 ? -1 : 1. */
> >> (simplify
> >> (div:C @0 (abs @0))
> >> (if (INTEGRAL_TYPE_P (type)
> >> @@ -921,6 +921,31 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> >> (bitop:c @0 (bit_not (bitop:cs @0 @1)))
> >> (bitop @0 (bit_not @1))))
> >>
> >> +/* (~x & y) | ~(x | y) -> ~x */
> >> +(simplify
> >> + (bit_ior:c (bit_and:c (bit_not@2 @0) @1) (bit_not (bit_ior:c @0 @1)))
> >> + @2)
> >> +
> >> +/* (x | y) ^ (x | ~y) -> ~x */
> >> +(simplify
> >> + (bit_xor:c (bit_ior:c @0 @1) (bit_ior:c @0 (bit_not @1)))
> >> + (bit_not @0))
> >> +
> >> +/* (x & y) | ~(x | y) -> ~(x ^ y) */
> >> +(simplify
> >> + (bit_ior:c (bit_and @0 @1) (bit_not:s (bit_ior:s @0 @1)))
> >
> > I think this misses :cs on the bit_and.
>
> For :c, shouldn't canonicalization make the order of @0 and @1 consistent
> for bit_and and bit_ior?
Hmm, probably yes. This all makes me think that the :c should better be
placed automagically by genmatch...
> >> + (bit_not (bit_xor @0 @1)))
> >> +
> >> +/* (~x | y) ^ (x ^ y) -> x | ~y */
> >> +(simplify
> >> + (bit_xor:c (bit_ior:cs (bit_not @0) @1) (bit_xor:c @0 @1))
> >> + (bit_ior @0 (bit_not @1)))
> >
> > :s on the bit_xor
> >
> >> +/* (x ^ y) | ~(x | y) -> ~(x & y) */
> >> +(simplify
> >> + (bit_ior:c (bit_xor @0 @1) (bit_not:s (bit_ior @0 @1)))
> >> + (bit_not (bit_and @0 @1)))
> >
> > :cs on the bit_xor, :s on the second bit_ior
> >
> > Otherwise looks OK to me.
>
> --
> Marc Glisse
