From: Richard Biener <richard.guenther@gmail.com>
To: Andrew Pinski <apinski@marvell.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Fix PR110726: a | (a == b) can sometimes produce wrong code
Date: Wed, 19 Jul 2023 09:14:55 +0200 [thread overview]
Message-ID: <CAFiYyc0LK4+utC5JM4HZeiHwtkPDjwPoZS=UjMmE+3y0VQmWhg@mail.gmail.com> (raw)
In-Reply-To: <20230719015221.1383859-1-apinski@marvell.com>
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?
> + && 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
>
next prev parent reply other threads:[~2023-07-19 7:15 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 [this message]
2023-07-19 7:32 ` Andrew Pinski
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='CAFiYyc0LK4+utC5JM4HZeiHwtkPDjwPoZS=UjMmE+3y0VQmWhg@mail.gmail.com' \
--to=richard.guenther@gmail.com \
--cc=apinski@marvell.com \
--cc=gcc-patches@gcc.gnu.org \
/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).