public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH] Swap loop splitting and final value replacement
@ 2023-08-03  9:09 Richard Biener
  0 siblings, 0 replies; 2+ messages in thread
From: Richard Biener @ 2023-08-03  9:09 UTC (permalink / raw)
  To: gcc-patches; +Cc: Jan Hubicka

The following swaps the loop splitting pass and the final value
replacement pass to avoid keeping the IV of the earlier loop
live when not necessary.  The existing gcc.target/i386/pr87007-5.c
testcase shows that we otherwise fail to elide an empty loop
later.  I don't see any good reason why loop splitting would need
final value replacement, all exit values honor the constraints
we place on loop header PHIs automatically.

Bootstrap and regtest running on x86_64-unknown-linux-gnu, I plan
to install this if testing succeeds.

Richard.

	* passes.def: Exchange loop splitting and final value
	replacement passes.

	* gcc.target/i386/pr87007-5.c: Make sure we split the loop
	and eliminate both in the end.
---
 gcc/passes.def                            | 2 +-
 gcc/testsuite/gcc.target/i386/pr87007-5.c | 4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/gcc/passes.def b/gcc/passes.def
index f2893ae8a8b..ef5a21afe49 100644
--- a/gcc/passes.def
+++ b/gcc/passes.def
@@ -282,8 +282,8 @@ along with GCC; see the file COPYING3.  If not see
 	     form if possible.  */
 	  NEXT_PASS (pass_tree_loop_init);
 	  NEXT_PASS (pass_tree_unswitch);
-	  NEXT_PASS (pass_scev_cprop);
 	  NEXT_PASS (pass_loop_split);
+	  NEXT_PASS (pass_scev_cprop);
 	  NEXT_PASS (pass_loop_versioning);
 	  NEXT_PASS (pass_loop_jam);
 	  /* All unswitching, final value replacement and splitting can expose
diff --git a/gcc/testsuite/gcc.target/i386/pr87007-5.c b/gcc/testsuite/gcc.target/i386/pr87007-5.c
index b36e81c270c..a6cdf11522e 100644
--- a/gcc/testsuite/gcc.target/i386/pr87007-5.c
+++ b/gcc/testsuite/gcc.target/i386/pr87007-5.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-Ofast -march=skylake-avx512 -mfpmath=sse -fno-tree-vectorize" } */
+/* { dg-options "-Ofast -march=skylake-avx512 -mfpmath=sse -fno-tree-vectorize -fdump-tree-cddce3-details -fdump-tree-lsplit-optimized" } */
 /* Load of d2/d3 is hoisted out, vrndscalesd will reuse loades register to avoid partial dependence.  */
 
 #include<math.h>
@@ -15,4 +15,6 @@ foo (int n, int k)
       d1 = sqrt (d3);
 }
 
+/* { dg-final { scan-tree-dump "optimized: loop split" "lsplit" } } */
+/* { dg-final { scan-tree-dump-times "removing loop" 2 "cddce3" } } */
 /* { dg-final { scan-assembler-times "vxorps\[^\n\r\]*xmm\[0-9\]" 0 } } */
-- 
2.35.3

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

* Re: [PATCH] Swap loop splitting and final value replacement
@ 2023-08-03  9:16 Jan Hubicka
  0 siblings, 0 replies; 2+ messages in thread
From: Jan Hubicka @ 2023-08-03  9:16 UTC (permalink / raw)
  To: Richard Biener; +Cc: gcc-patches

> The following swaps the loop splitting pass and the final value
> replacement pass to avoid keeping the IV of the earlier loop
> live when not necessary.  The existing gcc.target/i386/pr87007-5.c
> testcase shows that we otherwise fail to elide an empty loop
> later.  I don't see any good reason why loop splitting would need
> final value replacement, all exit values honor the constraints
> we place on loop header PHIs automatically.
> 
> Bootstrap and regtest running on x86_64-unknown-linux-gnu, I plan
> to install this if testing succeeds.
Thanks! I was just looking into the same. This should let us to turn the
split loop into non-loop for hmmer.

Honza

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

end of thread, other threads:[~2023-08-03  9:16 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-08-03  9:09 [PATCH] Swap loop splitting and final value replacement Richard Biener
2023-08-03  9:16 Jan Hubicka

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