diff mbox series

PR middle-end/109031: Fix final value replacement from narrower IVs.

Message ID 000601d954f3$ee202350$ca6069f0$@nextmovesoftware.com
State Accepted
Headers
Series PR middle-end/109031: Fix final value replacement from narrower IVs. |

Checks

Context Check Description
snail/gcc-patch-check success Github commit url

Commit Message

Roger Sayle March 12, 2023, 3:04 p.m. UTC 
  This patch fixes a P1 regression, a problem with my February 2022 patch
to improve folding for final value replacement:
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590618.html

The motivation for the original patch is that because we know the number
of loop iterations can't be negative, final value expressions such as
(int) ((unsigned int) x + 4294967295) + 1 can be simplified to x,
as this is effectively ((x - 1) + 1) without overflow.

The bug/oversight is that using integer_all_onesp to check for the
implicit tree constant -1 it didn't consider that the inner (unsigned)
type might be narrower than outer result type.  For the case in the PR,
(int)((unsigned char)x + 255) + 1 gets simplified to (int)x, but when
x is originally zero, the correct result should be 256.

The fix is to check that the inner type's precision (the width of the
subtraction) is at least as wide as the result type (that of the addition).

This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check, both with and without --target_board=unix{-m32},
with no new failures.  I've also added a test for signed types,
but without -fwrapv this invokes undefined behaviour, and with
-fwrapv it doesn't exhibit the problem in the PR.

Ok for mainline?


2023-03-12  Roger Sayle  <roger@nextmovesoftware.com>

gcc/ChangeLog
	PR middle-end/109031
	* tree-chrec.cc (chrec_apply): When folding "{a, +, a} (x-1)",
	ensure that the type of x is as wide or wider than the type of a.

gcc/testsuite/ChangeLog
	PR middle-end/109031
	* gcc.dg/tree-ssa/pr109031-1.c: New test case.
	* gcc.dg/tree-ssa/pr109031-2.c: Likewise.

Thanks in advance, and my apologies to the breakage/inconvenience.
Roger
--

Comments

Jeff Law March 12, 2023, 5:07 p.m. UTC | #1 
On 3/12/23 09:04, Roger Sayle wrote:
> 
> This patch fixes a P1 regression, a problem with my February 2022 patch
> to improve folding for final value replacement:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590618.html
> 
> The motivation for the original patch is that because we know the number
> of loop iterations can't be negative, final value expressions such as
> (int) ((unsigned int) x + 4294967295) + 1 can be simplified to x,
> as this is effectively ((x - 1) + 1) without overflow.
> 
> The bug/oversight is that using integer_all_onesp to check for the
> implicit tree constant -1 it didn't consider that the inner (unsigned)
> type might be narrower than outer result type.  For the case in the PR,
> (int)((unsigned char)x + 255) + 1 gets simplified to (int)x, but when
> x is originally zero, the correct result should be 256.
> 
> The fix is to check that the inner type's precision (the width of the
> subtraction) is at least as wide as the result type (that of the addition).
> 
> This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
> and make -k check, both with and without --target_board=unix{-m32},
> with no new failures.  I've also added a test for signed types,
> but without -fwrapv this invokes undefined behaviour, and with
> -fwrapv it doesn't exhibit the problem in the PR.
> 
> Ok for mainline?
> 
> 
> 2023-03-12  Roger Sayle  <roger@nextmovesoftware.com>
> 
> gcc/ChangeLog
> 	PR middle-end/109031
> 	* tree-chrec.cc (chrec_apply): When folding "{a, +, a} (x-1)",
> 	ensure that the type of x is as wide or wider than the type of a.
> 
> gcc/testsuite/ChangeLog
> 	PR middle-end/109031
> 	* gcc.dg/tree-ssa/pr109031-1.c: New test case.
> 	* gcc.dg/tree-ssa/pr109031-2.c: Likewise.
OK.
jeff
diff mbox series

Patch

diff --git a/gcc/tree-chrec.cc b/gcc/tree-chrec.cc
index f93d8dc..2f67581 100644
--- a/gcc/tree-chrec.cc
+++ b/gcc/tree-chrec.cc
@@ -623,7 +623,9 @@  chrec_apply (unsigned var,
 	  else if (operand_equal_p (CHREC_LEFT (chrec), chrecr)
 		   && TREE_CODE (x) == PLUS_EXPR
 		   && integer_all_onesp (TREE_OPERAND (x, 1))
-		   && !POINTER_TYPE_P (type))
+		   && !POINTER_TYPE_P (type)
+		   && TYPE_PRECISION (TREE_TYPE (x))
+		      >= TYPE_PRECISION (type))
 	    {
 	      /* We know the number of iterations can't be negative.
 		 So {a, +, a} (x-1) -> "a*x".  */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr109031-1.c b/gcc/testsuite/gcc.dg/tree-ssa/pr109031-1.c
new file mode 100644
index 0000000..84e1a08
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr109031-1.c
@@ -0,0 +1,39 @@ 
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+unsigned char uc;
+unsigned short us;
+
+void testuc() {
+  unsigned int g = 0;
+  unsigned int *p1 = &g;
+  unsigned char *p2 = &uc;
+
+  do {
+    (*p1)++;
+    (*p2)--;
+  } while (uc);
+
+  if (g != 256)
+    __builtin_abort();
+}
+
+void testus() {
+  unsigned int g = 0;
+  unsigned int *p1 = &g;
+  unsigned short *p2 = &us;
+
+  do {
+    (*p1)++;
+    (*p2)--;
+  } while (us);
+
+  if (g != 65536)
+    __builtin_abort();
+}
+
+int main() {
+  testuc();
+  testus();
+  return 0;
+}
+
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr109031-2.c b/gcc/testsuite/gcc.dg/tree-ssa/pr109031-2.c
new file mode 100644
index 0000000..6f28b3b
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr109031-2.c
@@ -0,0 +1,39 @@ 
+/* { dg-do run } */
+/* { dg-options "-O2 -fwrapv" } */
+signed char sc;
+signed short ss;
+
+void testsc() {
+  unsigned int g = 0;
+  unsigned int *p1 = &g;
+  signed char *p2 = &sc;
+
+  do {
+    (*p1)++;
+    (*p2)--;
+  } while (sc);
+
+  if (g != 256)
+    __builtin_abort();
+}
+
+void testss() {
+  unsigned int g = 0;
+  unsigned int *p1 = &g;
+  signed short *p2 = &ss;
+
+  do {
+    (*p1)++;
+    (*p2)--;
+  } while (ss);
+
+  if (g != 65536)
+    __builtin_abort();
+}
+
+int main() {
+  testsc();
+  testss();
+  return 0;
+}
+