public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andrew Pinski <pinskia@gmail.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: Andrew Pinski <apinski@marvell.com>, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Fix PR110726: a | (a == b) can sometimes produce wrong code
Date: Wed, 19 Jul 2023 00:32:08 -0700	[thread overview]
Message-ID: <CA+=Sn1=uyf2vYwdmFBbU9YXAF+mUNLFFowmTs=6vZWQnwjNYqA@mail.gmail.com> (raw)
In-Reply-To: <CAFiYyc0LK4+utC5JM4HZeiHwtkPDjwPoZS=UjMmE+3y0VQmWhg@mail.gmail.com>

On Wed, Jul 19, 2023 at 12:16 AM Richard Biener via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> On Wed, Jul 19, 2023 at 3:53 AM Andrew Pinski via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
> >
> > So I had missed/forgot that EQ_EXPR could have an non boolean
> > type for generic when I implemented r14-2556-g0407ae8a7732d9.
> > This patch adds check for one bit precision intergal type
> > which fixes the problem.
> >
> > OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
> >
> >         PR tree-optimization/110726
> >
> > gcc/ChangeLog:
> >
> >         * match.pd ((a|b)&(a==b),a|(a==b),(a&b)|(a==b)):
> >         Add checks to make sure the type was one bit precision
> >         intergal type.
> >
> > gcc/testsuite/ChangeLog:
> >
> >         * gcc.c-torture/execute/bitops-1.c: New test.
> > ---
> >  gcc/match.pd                                  | 12 +++++--
> >  .../gcc.c-torture/execute/bitops-1.c          | 33 +++++++++++++++++++
> >  2 files changed, 42 insertions(+), 3 deletions(-)
> >  create mode 100644 gcc/testsuite/gcc.c-torture/execute/bitops-1.c
> >
> > diff --git a/gcc/match.pd b/gcc/match.pd
> > index 054e6585876..4dfe92623f7 100644
> > --- a/gcc/match.pd
> > +++ b/gcc/match.pd
> > @@ -1229,7 +1229,9 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> >  /* (a | b) & (a == b)  -->  a & b (boolean version of the above).  */
> >  (simplify
> >   (bit_and:c (bit_ior @0 @1) (nop_convert? (eq:c @0 @1)))
> > - (bit_and @0 @1))
> > + (if (INTEGRAL_TYPE_P (TREE_TYPE (@0))
>
> that's really a constraint on 'type', not sure if it would be clearer
> to test that.
> What's the nop_convert you've seen in practice here?  With integer comparison
> result shouldn't those be convert? instead?

The case were nop_convert happen would happen is:
```
struct f
{
  signed a:1;
  signed b:1;
  signed c:1;
};

void f(struct f t, struct f *t1)
{
  t.c = (t.a == t.b);
  t1->c =   (t.a | t.b) & t.c;
}
```
I know the above does not show up much but it definitely can show up.

In the testcase in the bug report the EQ_EXPR didn't have convert
around it but the type was just changed to be the long type and we
cannot treat the `a == b` similar as `~(a^b)` which is only works for
1 bit integers (unsigned or signed).

Thanks,
Andrew Pinski

>
> > +      && TYPE_PRECISION (TREE_TYPE (@0)) == 1)
> > +  (bit_and @0 @1)))
> >
> >  /* a | ~(a ^ b)  -->  a | ~b  */
> >  (simplify
> > @@ -1239,7 +1241,9 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> >  /* a | (a == b)  -->  a | (b^1) (boolean version of the above). */
> >  (simplify
> >   (bit_ior:c @0 (nop_convert? (eq:c @0 @1)))
> > - (bit_ior @0 (bit_xor @1 { build_one_cst (type); })))
> > + (if (INTEGRAL_TYPE_P (TREE_TYPE (@0))
> > +      && TYPE_PRECISION (TREE_TYPE (@0)) == 1)
> > +  (bit_ior @0 (bit_xor @1 { build_one_cst (type); }))))
> >
> >  /* (a | b) | (a &^ b)  -->  a | b  */
> >  (for op (bit_and bit_xor)
> > @@ -1255,7 +1259,9 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> >  /* (a & b) | (a == b)  -->  a == b  */
> >  (simplify
> >   (bit_ior:c (bit_and:c @0 @1) (nop_convert?@2 (eq @0 @1)))
> > - @2)
> > + (if (INTEGRAL_TYPE_P (TREE_TYPE (@0))
> > +      && TYPE_PRECISION (TREE_TYPE (@0)) == 1)
> > +  @2))
> >
> >  /* ~(~a & b)  -->  a | ~b  */
> >  (simplify
> > diff --git a/gcc/testsuite/gcc.c-torture/execute/bitops-1.c b/gcc/testsuite/gcc.c-torture/execute/bitops-1.c
> > new file mode 100644
> > index 00000000000..cfaa6b9fd26
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.c-torture/execute/bitops-1.c
> > @@ -0,0 +1,33 @@
> > +/* PR tree-optimization/110726 */
> > +
> > +#define DECLS(n,VOL)                   \
> > +__attribute__((noinline,noclone))      \
> > +int h##n(VOL int A, VOL int B){                \
> > +    return (A | B) & (A == B);         \
> > +}                                      \
> > +__attribute__((noinline,noclone))      \
> > +int i##n(VOL int A, VOL int B){                \
> > +    return A | (A == B);               \
> > +}                                      \
> > +__attribute__((noinline,noclone))      \
> > +int k##n(VOL int A, VOL int B){                \
> > +    return (A & B) | (A == B);         \
> > +}                                      \
> > +
> > +DECLS(0,)
> > +DECLS(1,volatile)
> > +
> > +int values[] = { 0, 1, 2, 3, -1, -2, -3, 0x10080 };
> > +int numvalues = sizeof(values)/sizeof(values[0]);
> > +
> > +int main(){
> > +    for(int A = 0; A < numvalues; A++)
> > +      for(int B = 0; B < numvalues; B++)
> > +       {
> > +         int a = values[A];
> > +         int b = values[B];
> > +         if (h0 (a, b) != h1 (a, b)) __builtin_abort();
> > +         if (i0 (a, b) != i1 (a, b)) __builtin_abort();
> > +         if (k0 (a, b) != k1 (a, b)) __builtin_abort();
> > +       }
> > +}
> > --
> > 2.31.1
> >

  reply	other threads:[~2023-07-19  7:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-19  1:52 Andrew Pinski
2023-07-19  7:14 ` Richard Biener
2023-07-19  7:32   ` Andrew Pinski [this message]
2023-07-19  8:14     ` Richard Biener

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+=Sn1=uyf2vYwdmFBbU9YXAF+mUNLFFowmTs=6vZWQnwjNYqA@mail.gmail.com' \
    --to=pinskia@gmail.com \
    --cc=apinski@marvell.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.guenther@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).