public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Aldy Hernandez <aldyh@redhat.com>
To: GCC patches <gcc-patches@gcc.gnu.org>
Cc: Andrew MacLeod <amacleod@redhat.com>, Aldy Hernandez <aldyh@redhat.com>
Subject: [COMMITTED] [PR tree-optimization/107312] Make range_true_and_false work with 1-bit signed types.
Date: Wed, 19 Oct 2022 16:02:12 +0200	[thread overview]
Message-ID: <20221019140212.44796-1-aldyh@redhat.com> (raw)

range_true_and_false() returns a range of [0,1], which for a 1-bit
signed integer gets passed to the irange setter as [0, -1].  These
endpoints are out of order and cause an ICE.  Through some dumb luck,
the legacy code swaps out of order endpoints, because old VRP would
sometimes pass endpoints reversed, depending on the setter to fix
them.  This swapping does not happen for non-legacy, hence the ICE.

The right thing to do (apart from killing legacy and 1-bit signed
integers ;-)), is to avoid passing out of order endpoints for 1-bit
signed integers.  For that matter, a range of [-1, 0] (signed) or
[0, 1] (unsigned) is just varying.

	PR tree-optimization/107312

gcc/ChangeLog:

	* range.h (range_true_and_false): Special case 1-bit signed types.
	* value-range.cc (range_tests_misc): New test.

gcc/testsuite/ChangeLog:

	* gcc.target/i386/pr107312.c: New test.
---
 gcc/range.h                              |  2 ++
 gcc/testsuite/gcc.target/i386/pr107312.c | 11 +++++++++++
 gcc/value-range.cc                       |  2 ++
 3 files changed, 15 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr107312.c

diff --git a/gcc/range.h b/gcc/range.h
index 8138d6f5515..ba3a6b2516f 100644
--- a/gcc/range.h
+++ b/gcc/range.h
@@ -50,6 +50,8 @@ static inline int_range<1>
 range_true_and_false (tree type)
 {
   unsigned prec = TYPE_PRECISION (type);
+  if (prec == 1)
+    return int_range<2> (type);
   return int_range<2> (type, wi::zero (prec), wi::one (prec));
 }
 
diff --git a/gcc/testsuite/gcc.target/i386/pr107312.c b/gcc/testsuite/gcc.target/i386/pr107312.c
new file mode 100644
index 00000000000..b4180e3bd7d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr107312.c
@@ -0,0 +1,11 @@
+// { dg-do compile }
+// { dg-options "-mavx512vbmi -O1 -ftree-loop-vectorize" }
+
+void
+foo (_Float16 *r, short int *a)
+{
+  int i;
+
+  for (i = 0; i < 32; ++i)
+    r[i] = !!a[i];
+}
diff --git a/gcc/value-range.cc b/gcc/value-range.cc
index 90d5e660684..511cd0ad767 100644
--- a/gcc/value-range.cc
+++ b/gcc/value-range.cc
@@ -3437,6 +3437,8 @@ range_tests_misc ()
     max.union_ (min);
     ASSERT_TRUE (max.varying_p ());
   }
+  // Test that we can set a range of true+false for a 1-bit signed int.
+  r0 = range_true_and_false (one_bit_type);
 
   // Test inversion of 1-bit signed integers.
   {
-- 
2.37.3


                 reply	other threads:[~2022-10-19 14:02 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20221019140212.44796-1-aldyh@redhat.com \
    --to=aldyh@redhat.com \
    --cc=amacleod@redhat.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).