[PATCH] tree-optimization/108482 - remove stray .LOOP_DIST_ALIAS calls

[PATCH] tree-optimization/108482 - remove stray .LOOP_DIST_ALIAS calls

[Richard Biener]

The following deals with .LOOP_DIST_ALIAS surviving vectorization
because any of the loops involved were elided between loop distribution
and vectorization.  As opposed to .LOOP_VECTORIZED which exists only
between if-conversion and vectorization with no intermediate passes
this is more difficult to deal with in advance and thus cleaning
up after vectorization looks better.  There's the unconditional
vector lowering pass which looks like a good place for this (for
SIMD uid we have pass_simduid_cleanup).

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

OK?

Thanks,
Richard.

	PR tree-optimization/108482
	* tree-vect-generic.cc (expand_vector_operations): Fold remaining
	.LOOP_DIST_ALIAS calls.

	* gcc.dg/torture/pr108482.c: New testcase.
---
 gcc/testsuite/gcc.dg/torture/pr108482.c | 18 ++++++++++++++++++
 gcc/tree-vect-generic.cc                |  8 ++++++++
 2 files changed, 26 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/torture/pr108482.c

diff --git a/gcc/testsuite/gcc.dg/torture/pr108482.c b/gcc/testsuite/gcc.dg/torture/pr108482.c
new file mode 100644
index 00000000000..8dc1169a9c5
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr108482.c
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+
+int g_30, g_261, g_263, func_1___trans_tmp_17;
+int **g_120;
+int *g_530;
+void func_1() {
+  int *l_29 = &g_30;
+  *l_29 = 1;
+  g_263 = 0;
+  for (; g_263 <= 1; g_263 += 1) {
+    g_530 = 0;
+    if (*l_29) {
+      char *l_1694 = (char *)&g_261;
+      *l_1694 &= **g_120;
+    } else
+      *l_29 ^= func_1___trans_tmp_17;
+  }
+}
diff --git a/gcc/tree-vect-generic.cc b/gcc/tree-vect-generic.cc
index 2e2d7567293..166a248f4b9 100644
--- a/gcc/tree-vect-generic.cc
+++ b/gcc/tree-vect-generic.cc
@@ -2398,6 +2398,14 @@ expand_vector_operations (void)
 	  if (maybe_clean_eh_stmt (gsi_stmt (gsi))
 	      && gimple_purge_dead_eh_edges (bb))
 	    cfg_changed = true;
+	  /* If a .LOOP_DIST_ALIAS call prevailed loops got elided
+	     before vectorization got a chance to get at them.  Simply
+	     fold as if loop distribution wasn't performed.  */
+	  if (gimple_call_internal_p (gsi_stmt (gsi), IFN_LOOP_DIST_ALIAS))
+	    {
+	      fold_loop_internal_call (gsi_stmt (gsi), boolean_false_node);
+	      cfg_changed = true;
+	    }
 	}
     }
 
-- 
2.35.3

Re: [PATCH] tree-optimization/108482 - remove stray .LOOP_DIST_ALIAS calls

[Jakub Jelinek]

On Mon, Jan 23, 2023 at 11:09:43AM +0100, Richard Biener wrote:
> The following deals with .LOOP_DIST_ALIAS surviving vectorization
> because any of the loops involved were elided between loop distribution
> and vectorization.  As opposed to .LOOP_VECTORIZED which exists only
> between if-conversion and vectorization with no intermediate passes
> this is more difficult to deal with in advance and thus cleaning
> up after vectorization looks better.  There's the unconditional
> vector lowering pass which looks like a good place for this (for
> SIMD uid we have pass_simduid_cleanup).
> 
> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
> 
> OK?

I admit I didn't know something like LOOP_DIST_ALIAS even exist until
today.
Anyway, I wonder if there is still time to clean up during/after
veclower21.
I see fold_loop_internal_call propagates the return value to immediate
uses and cfg_changed means we'll clean up the cfg, is that enough?

	Jakub

Re: [PATCH] tree-optimization/108482 - remove stray .LOOP_DIST_ALIAS calls

[Richard Biener]

On Mon, 23 Jan 2023, Jakub Jelinek wrote:

> On Mon, Jan 23, 2023 at 11:09:43AM +0100, Richard Biener wrote:
> > The following deals with .LOOP_DIST_ALIAS surviving vectorization
> > because any of the loops involved were elided between loop distribution
> > and vectorization.  As opposed to .LOOP_VECTORIZED which exists only
> > between if-conversion and vectorization with no intermediate passes
> > this is more difficult to deal with in advance and thus cleaning
> > up after vectorization looks better.  There's the unconditional
> > vector lowering pass which looks like a good place for this (for
> > SIMD uid we have pass_simduid_cleanup).
> > 
> > Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
> > 
> > OK?
> 
> I admit I didn't know something like LOOP_DIST_ALIAS even exist until
> today.
> Anyway, I wonder if there is still time to clean up during/after
> veclower21.

That's what the patch does, but maybe I misunderstood the question.

> I see fold_loop_internal_call propagates the return value to immediate
> uses and cfg_changed means we'll clean up the cfg, is that enough?

It's enough to get rid of the internal function call which will ICE
if it reaches RTL expansion.  The earliest point to get rid of them
is in the loop vectorizer but for the testcase at hand this requires
a walk of the whole IL where we cut the whole vectorizer pass with
the number-of-loops in function check currently.

Richard.

Re: [PATCH] tree-optimization/108482 - remove stray .LOOP_DIST_ALIAS calls

[Jakub Jelinek]

On Mon, Jan 23, 2023 at 10:28:01AM +0000, Richard Biener wrote:
> On Mon, 23 Jan 2023, Jakub Jelinek wrote:
> 
> > On Mon, Jan 23, 2023 at 11:09:43AM +0100, Richard Biener wrote:
> > > The following deals with .LOOP_DIST_ALIAS surviving vectorization
> > > because any of the loops involved were elided between loop distribution
> > > and vectorization.  As opposed to .LOOP_VECTORIZED which exists only
> > > between if-conversion and vectorization with no intermediate passes
> > > this is more difficult to deal with in advance and thus cleaning
> > > up after vectorization looks better.  There's the unconditional
> > > vector lowering pass which looks like a good place for this (for
> > > SIMD uid we have pass_simduid_cleanup).
> > > 
> > > Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
> > > 
> > > OK?
> > 
> > I admit I didn't know something like LOOP_DIST_ALIAS even exist until
> > today.
> > Anyway, I wonder if there is still time to clean up during/after
> > veclower21.
> 
> That's what the patch does, but maybe I misunderstood the question.
> 
> > I see fold_loop_internal_call propagates the return value to immediate
> > uses and cfg_changed means we'll clean up the cfg, is that enough?
> 
> It's enough to get rid of the internal function call which will ICE
> if it reaches RTL expansion.  The earliest point to get rid of them
> is in the loop vectorizer but for the testcase at hand this requires
> a walk of the whole IL where we cut the whole vectorizer pass with
> the number-of-loops in function check currently.

Ok then.

	Jakub