On Mon, Sep 02, 2024 at 11:25:36AM -0700, Andrew Pinski wrote:
> On Mon, Sep 2, 2024 at 11:20 AM Jakub Jelinek <ja...@redhat.com> wrote:
> >
> > On Mon, Aug 26, 2024 at 02:42:31PM +0800, Haochen Jiang wrote:
> > > * match.pd: Optimize (and ordered non-equal) to
> > > (not (or unordered equal))
> > >
> > > gcc/testsuite/ChangeLog:
> > >
> > > * gcc.target/i386/optimize_one.c: New test.
> >
> > The testcase FAILs on i686-linux, because it uses -mfpmath=sse
> > without enabling -msse2.
> >
> > I've committed the following fix as obvious to fix that.
> >
> > > --- a/gcc/match.pd
> > > +++ b/gcc/match.pd
> > > @@ -6636,6 +6636,9 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> > > (ltgt @0 @0)
> > > (if (!flag_trapping_math || !tree_expr_maybe_nan_p (@0))
> > > { constant_boolean_node (false, type); }))
> > > +(simplify
> > > + (bit_and (ordered @0 @1) (ne @0 @1))
> > > + (bit_not (uneq @0 @1)))
> >
> > I wonder whether there shouldn't be some :c (e.g. on bit_and and maybe
> > ne too), because ordered is commutative and so is ne and so is bit_and,
> > and perhaps you want to match also (bit_and (ne @0 @1) (ordered @1 @0))
> > etc. What about negation of this (bit_ior (unordered @0 @1) (eq @0 @1))?
>
> The :c is needed for bit_and for sure. BUT should not needed for
> ordered/ne though because the canonicalization of the operations
> should have the operands in the same order as `a ordered b` is the
> same as `b ordered a`.
Maybe. Also, isn't (bit_not (uneq @0 @1)) (ltgt @0 @1) ?
Jakub
