public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH] tree-optimization/106198 - CFG cleanup vs LC SSA
@ 2022-07-05 14:03 Richard Biener
  0 siblings, 0 replies; 3+ messages in thread
From: Richard Biener @ 2022-07-05 14:03 UTC (permalink / raw)
  To: gcc-patches

This is another case like PR106182 where for the 2nd testcase in
the bug there are no removed or discovered loops but still changing
loop exits invalidates LC SSA and it is not enough to just scan for
uses in the blocks that changed loop depth.  One might argue that
if we'd include former exit destinations we'd pick up the original
LC SSA use but for virtuals on block merging we'd have propagated
those out (while for regular uses we insert copies).  CFG cleanup
can also be entered with loops needing fixup so any heuristics
based on loop structure are bound to fail.

Boostrapped and tested on x86_64-unknown-linux-gnu, pushed.

	PR tree-optimization/106198
	* tree-cfgcleanup.cc (repair_loop_structures): Always do a
	full LC SSA rewrite but only if any blocks changed loop
	depth.

	* gcc.dg/pr106198.c: New testcase.
---
 gcc/testsuite/gcc.dg/pr106198.c | 22 ++++++++++++++++++++++
 gcc/tree-cfgcleanup.cc          |  6 +++---
 2 files changed, 25 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/pr106198.c

diff --git a/gcc/testsuite/gcc.dg/pr106198.c b/gcc/testsuite/gcc.dg/pr106198.c
new file mode 100644
index 00000000000..00d2758efa7
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr106198.c
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options "-O3" } */
+
+int printf(const char *, ...);
+long a;
+int b;
+volatile int c;
+int main() {
+  long e = a;
+  int f = a;
+ L:
+  if (b > 0) {
+    printf("0");
+    goto L;
+  }
+  if (f) {
+    printf("%ld", (long)b);
+    goto L;
+  }
+  e >= b && c;
+  return 0;
+}
diff --git a/gcc/tree-cfgcleanup.cc b/gcc/tree-cfgcleanup.cc
index 3b24e021b6b..b9ff6896ce6 100644
--- a/gcc/tree-cfgcleanup.cc
+++ b/gcc/tree-cfgcleanup.cc
@@ -1183,9 +1183,9 @@ repair_loop_structures (void)
      become unreachable by back edges from latch).  Also a former
      irreducible loop can become reducible - in this case force a full
      rewrite into loop-closed SSA form.  */
-  if (loops_state_satisfies_p (LOOP_CLOSED_SSA))
-    rewrite_into_loop_closed_ssa (n_new_or_deleted_loops ? NULL : changed_bbs,
-				  TODO_update_ssa);
+  if (loops_state_satisfies_p (LOOP_CLOSED_SSA)
+      && (!bitmap_empty_p (changed_bbs) || n_new_or_deleted_loops))
+    rewrite_into_loop_closed_ssa (NULL, TODO_update_ssa);
 
   BITMAP_FREE (changed_bbs);
 
-- 
2.35.3

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [PATCH] tree-optimization/106198 - CFG cleanup vs LC SSA
@ 2022-07-05 14:03 Richard Biener
  0 siblings, 0 replies; 3+ messages in thread
From: Richard Biener @ 2022-07-05 14:03 UTC (permalink / raw)
  To: gcc-patches

This is another case like PR106182 where for the 2nd testcase in
the bug there are no removed or discovered loops but still changing
loop exits invalidates LC SSA and it is not enough to just scan for
uses in the blocks that changed loop depth.  One might argue that
if we'd include former exit destinations we'd pick up the original
LC SSA use but for virtuals on block merging we'd have propagated
those out (while for regular uses we insert copies).  CFG cleanup
can also be entered with loops needing fixup so any heuristics
based on loop structure are bound to fail.

Boostrapped and tested on x86_64-unknown-linux-gnu, pushed.

	PR tree-optimization/106198
	* tree-cfgcleanup.cc (repair_loop_structures): Always do a
	full LC SSA rewrite but only if any blocks changed loop
	depth.

	* gcc.dg/pr106198.c: New testcase.
---
 gcc/testsuite/gcc.dg/pr106198.c | 22 ++++++++++++++++++++++
 gcc/tree-cfgcleanup.cc          |  6 +++---
 2 files changed, 25 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/pr106198.c

diff --git a/gcc/testsuite/gcc.dg/pr106198.c b/gcc/testsuite/gcc.dg/pr106198.c
new file mode 100644
index 00000000000..00d2758efa7
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr106198.c
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options "-O3" } */
+
+int printf(const char *, ...);
+long a;
+int b;
+volatile int c;
+int main() {
+  long e = a;
+  int f = a;
+ L:
+  if (b > 0) {
+    printf("0");
+    goto L;
+  }
+  if (f) {
+    printf("%ld", (long)b);
+    goto L;
+  }
+  e >= b && c;
+  return 0;
+}
diff --git a/gcc/tree-cfgcleanup.cc b/gcc/tree-cfgcleanup.cc
index 3b24e021b6b..b9ff6896ce6 100644
--- a/gcc/tree-cfgcleanup.cc
+++ b/gcc/tree-cfgcleanup.cc
@@ -1183,9 +1183,9 @@ repair_loop_structures (void)
      become unreachable by back edges from latch).  Also a former
      irreducible loop can become reducible - in this case force a full
      rewrite into loop-closed SSA form.  */
-  if (loops_state_satisfies_p (LOOP_CLOSED_SSA))
-    rewrite_into_loop_closed_ssa (n_new_or_deleted_loops ? NULL : changed_bbs,
-				  TODO_update_ssa);
+  if (loops_state_satisfies_p (LOOP_CLOSED_SSA)
+      && (!bitmap_empty_p (changed_bbs) || n_new_or_deleted_loops))
+    rewrite_into_loop_closed_ssa (NULL, TODO_update_ssa);
 
   BITMAP_FREE (changed_bbs);
 
-- 
2.35.3

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [PATCH] tree-optimization/106198 - CFG cleanup vs LC SSA
@ 2022-07-05 14:03 Richard Biener
  0 siblings, 0 replies; 3+ messages in thread
From: Richard Biener @ 2022-07-05 14:03 UTC (permalink / raw)
  To: gcc-patches

This is another case like PR106182 where for the 2nd testcase in
the bug there are no removed or discovered loops but still changing
loop exits invalidates LC SSA and it is not enough to just scan for
uses in the blocks that changed loop depth.  One might argue that
if we'd include former exit destinations we'd pick up the original
LC SSA use but for virtuals on block merging we'd have propagated
those out (while for regular uses we insert copies).  CFG cleanup
can also be entered with loops needing fixup so any heuristics
based on loop structure are bound to fail.

Boostrapped and tested on x86_64-unknown-linux-gnu, pushed.

	PR tree-optimization/106198
	* tree-cfgcleanup.cc (repair_loop_structures): Always do a
	full LC SSA rewrite but only if any blocks changed loop
	depth.

	* gcc.dg/pr106198.c: New testcase.
---
 gcc/testsuite/gcc.dg/pr106198.c | 22 ++++++++++++++++++++++
 gcc/tree-cfgcleanup.cc          |  6 +++---
 2 files changed, 25 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/pr106198.c

diff --git a/gcc/testsuite/gcc.dg/pr106198.c b/gcc/testsuite/gcc.dg/pr106198.c
new file mode 100644
index 00000000000..00d2758efa7
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr106198.c
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options "-O3" } */
+
+int printf(const char *, ...);
+long a;
+int b;
+volatile int c;
+int main() {
+  long e = a;
+  int f = a;
+ L:
+  if (b > 0) {
+    printf("0");
+    goto L;
+  }
+  if (f) {
+    printf("%ld", (long)b);
+    goto L;
+  }
+  e >= b && c;
+  return 0;
+}
diff --git a/gcc/tree-cfgcleanup.cc b/gcc/tree-cfgcleanup.cc
index 3b24e021b6b..b9ff6896ce6 100644
--- a/gcc/tree-cfgcleanup.cc
+++ b/gcc/tree-cfgcleanup.cc
@@ -1183,9 +1183,9 @@ repair_loop_structures (void)
      become unreachable by back edges from latch).  Also a former
      irreducible loop can become reducible - in this case force a full
      rewrite into loop-closed SSA form.  */
-  if (loops_state_satisfies_p (LOOP_CLOSED_SSA))
-    rewrite_into_loop_closed_ssa (n_new_or_deleted_loops ? NULL : changed_bbs,
-				  TODO_update_ssa);
+  if (loops_state_satisfies_p (LOOP_CLOSED_SSA)
+      && (!bitmap_empty_p (changed_bbs) || n_new_or_deleted_loops))
+    rewrite_into_loop_closed_ssa (NULL, TODO_update_ssa);
 
   BITMAP_FREE (changed_bbs);
 
-- 
2.35.3

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-07-05 14:03 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-05 14:03 [PATCH] tree-optimization/106198 - CFG cleanup vs LC SSA Richard Biener
  -- strict thread matches above, loose matches on Subject: below --
2022-07-05 14:03 Richard Biener
2022-07-05 14:03 Richard Biener

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).