[PATCH] Fix parloops gimple_uid usage

[PATCH] Fix parloops gimple_uid usage

[Tom de Vries]

[-- Attachment #1: Type: text/plain, Size: 1751 bytes --]

Hi,

In tree-parloops.c:gather_scalar_reductions, we find the comment:
...
   /* As gimple_uid is used by the vectorizer in between
      vect_analyze_loop_form and destroy_loop_vec_info, we can set
      gimple_uid of reduc_phi stmts only now.  */
   reduction_list->traverse <void *, set_reduc_phi_uids> (NULL);
...

However, the usage of gimple_uid seems to extend until the 
free_stmt_vec_info_vec call at the end of parallelize_loops (the pass 
top-level function). During free_stmt_vec_info_vec we test for 
gimple_uid == 0 in vinfo_for_stmt.

By initializing all the phis in the function with -1 before using them 
in the reduct_phi stmts:
...
    destroy_loop_vec_info (simple_loop_info, true);
    destroy_loop_vec_info (simple_inner_loop_info, true);
 
 

    /* As gimple_uid is used by the vectorizer in between
       vect_analyze_loop_form and destroy_loop_vec_info, we can set
       gimple_uid of reduc_phi stmts only now. */
+  basic_block bb;
+  FOR_EACH_BB_FN (bb, cfun)
+    for (gsi = gsi_start_phis (bb); !gsi_end_p (gsi); gsi_next (&gsi))
+      gimple_set_uid (gsi_stmt (gsi), (unsigned int)-1);
  reduction_list->traverse <void *, set_reduc_phi_uids> (NULL);
...
we trigger a sigsegv in vinfo_for_stmt while trying to access 
stmt_vec_info_vec[4294967295 - 1].

This patch fixes that by moving the calls to init_stmt_vec_info_vec and
free_stmt_vec_info_vec from parallelize_loops and gather_scalar_reductions.

Furthermore, now that the gimple_uids are properly initialized, we can 
in reduction_phi:
- handle 0 (new phi) and -1 (initialized) values, both meaning the
   phi's not in the table, and
- assert that returned entries in fact match the phi argument.

OK for trunk if bootstrap and reg-test passes?

Thanks,
- Tom


[-- Attachment #2: 0001-Fix-parloops-gimple_uid-usage.patch --]
[-- Type: text/x-patch, Size: 2691 bytes --]

Fix parloops gimple_uid usage

2015-10-09  Tom de Vries  <tom@codesourcery.com>

	* tree-parloops.c (reduction_phi): Handle cases that gimple_uid is 0 or
	-1.  Add assert that returned entry matches phi argument.
	(parallelize_loops): Move calls to init_stmt_vec_info_vec and
	free_stmt_vec_info_vec ...
	(gather_scalar_reductions): ... here.  Initialize gimple_uids of phis
	with -1.
---
 gcc/tree-parloops.c | 21 +++++++++++++++++----
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/gcc/tree-parloops.c b/gcc/tree-parloops.c
index 741392b..7366318 100644
--- a/gcc/tree-parloops.c
+++ b/gcc/tree-parloops.c
@@ -237,9 +237,14 @@ reduction_phi (reduction_info_table_type *reduction_list, gimple *phi)
   if (reduction_list->elements () == 0 || phi == NULL)
     return NULL;
 
+  if (gimple_uid (phi) == (unsigned int)-1
+      || gimple_uid (phi) == 0)
+    return NULL;
+
   tmpred.reduc_phi = phi;
   tmpred.reduc_version = gimple_uid (phi);
   red = reduction_list->find (&tmpred);
+  gcc_assert (red == NULL || red->reduc_phi == phi);
 
   return red;
 }
@@ -2392,6 +2397,9 @@ gather_scalar_reductions (loop_p loop, reduction_info_table_type *reduction_list
   loop_vec_info simple_inner_loop_info = NULL;
   bool allow_double_reduc = true;
 
+  if (!stmt_vec_info_vec.exists ())
+    init_stmt_vec_info_vec ();
+
   simple_loop_info = vect_analyze_loop_form (loop);
   if (simple_loop_info == NULL)
     return;
@@ -2453,9 +2461,16 @@ gather_scalar_reductions (loop_p loop, reduction_info_table_type *reduction_list
   destroy_loop_vec_info (simple_loop_info, true);
   destroy_loop_vec_info (simple_inner_loop_info, true);
 
+  /* Release the claim on gimple_uid.  */
+  free_stmt_vec_info_vec ();
+
   /* As gimple_uid is used by the vectorizer in between vect_analyze_loop_form
-     and destroy_loop_vec_info, we can set gimple_uid of reduc_phi stmts
-     only now.  */
+     and free_stmt_vec_info_vec, we can set gimple_uid of reduc_phi stmts only
+     now.  */
+  basic_block bb;
+  FOR_EACH_BB_FN (bb, cfun)
+    for (gsi = gsi_start_phis (bb); !gsi_end_p (gsi); gsi_next (&gsi))
+      gimple_set_uid (gsi_stmt (gsi), (unsigned int)-1);
   reduction_list->traverse <void *, set_reduc_phi_uids> (NULL);
 }
 
@@ -2603,7 +2618,6 @@ parallelize_loops (void)
 
   gcc_obstack_init (&parloop_obstack);
   reduction_info_table_type reduction_list (10);
-  init_stmt_vec_info_vec ();
 
   FOR_EACH_LOOP (loop, 0)
     {
@@ -2695,7 +2709,6 @@ parallelize_loops (void)
 			 n_threads, &niter_desc);
     }
 
-  free_stmt_vec_info_vec ();
   obstack_free (&parloop_obstack, NULL);
 
   /* Parallelization will cause new function calls to be inserted through
-- 
1.9.1

Re: [PATCH] Fix parloops gimple_uid usage

[Richard Biener]

On Fri, Oct 9, 2015 at 11:09 PM, Tom de Vries <Tom_deVries@mentor.com> wrote:
> Hi,
>
> In tree-parloops.c:gather_scalar_reductions, we find the comment:
> ...
>   /* As gimple_uid is used by the vectorizer in between
>      vect_analyze_loop_form and destroy_loop_vec_info, we can set
>      gimple_uid of reduc_phi stmts only now.  */
>   reduction_list->traverse <void *, set_reduc_phi_uids> (NULL);
> ...
>
> However, the usage of gimple_uid seems to extend until the
> free_stmt_vec_info_vec call at the end of parallelize_loops (the pass
> top-level function). During free_stmt_vec_info_vec we test for gimple_uid ==
> 0 in vinfo_for_stmt.
>
> By initializing all the phis in the function with -1 before using them in
> the reduct_phi stmts:
> ...
>    destroy_loop_vec_info (simple_loop_info, true);
>    destroy_loop_vec_info (simple_inner_loop_info, true);
>
>
>
>    /* As gimple_uid is used by the vectorizer in between
>       vect_analyze_loop_form and destroy_loop_vec_info, we can set
>       gimple_uid of reduc_phi stmts only now. */
> +  basic_block bb;
> +  FOR_EACH_BB_FN (bb, cfun)
> +    for (gsi = gsi_start_phis (bb); !gsi_end_p (gsi); gsi_next (&gsi))
> +      gimple_set_uid (gsi_stmt (gsi), (unsigned int)-1);
>  reduction_list->traverse <void *, set_reduc_phi_uids> (NULL);
> ...
> we trigger a sigsegv in vinfo_for_stmt while trying to access
> stmt_vec_info_vec[4294967295 - 1].
>
> This patch fixes that by moving the calls to init_stmt_vec_info_vec and
> free_stmt_vec_info_vec from parallelize_loops and gather_scalar_reductions.
>
> Furthermore, now that the gimple_uids are properly initialized, we can in
> reduction_phi:
> - handle 0 (new phi) and -1 (initialized) values, both meaning the
>   phi's not in the table, and
> - assert that returned entries in fact match the phi argument.
>
> OK for trunk if bootstrap and reg-test passes?

Ok.

Richard.

> Thanks,
> - Tom
>

[PATCH, PR68460] Always call free_stmt_vec_info_vec in gather_scalar_reductions

[Tom de Vries]

[-- Attachment #1: Type: text/plain, Size: 1780 bytes --]

[ was: Re: [PATCH] Fix parloops gimple_uid usage ]

On 09/10/15 23:09, Tom de Vries wrote:
> @@ -2392,6 +2397,9 @@ gather_scalar_reductions (loop_p loop, reduction_info_table_type *reduction_list
>     loop_vec_info simple_inner_loop_info = NULL;
>     bool allow_double_reduc = true;
>
> +  if (!stmt_vec_info_vec.exists ())
> +    init_stmt_vec_info_vec ();
> +
>     simple_loop_info = vect_analyze_loop_form (loop);
>     if (simple_loop_info == NULL)
>       return;
> @@ -2453,9 +2461,16 @@ gather_scalar_reductions (loop_p loop, reduction_info_table_type *reduction_list
>     destroy_loop_vec_info (simple_loop_info, true);
>     destroy_loop_vec_info (simple_inner_loop_info, true);
>
> +  /* Release the claim on gimple_uid.  */
> +  free_stmt_vec_info_vec ();
> +

With the src/libgomp/testsuite/libgomp.c/pr46886.c testcase, compiled in 
addition with -ftree-vectorize, I ran into an ICE:
...
src/libgomp/testsuite/libgomp.c/pr46886.c:8:5: internal compiler error: 
in init_stmt_vec_info_vec, at tree-vect-stmts.c:8250
  int foo (void)
      ^~~

0x1196082 init_stmt_vec_info_vec()
	src/gcc/tree-vect-stmts.c:8250
0x11c3ed4 vectorize_loops()
	src/gcc/tree-vectorizer.c:510
0x10a7ea5 execute
	src/gcc/tree-ssa-loop.c:276
...

The ICE is caused by the fact that init_stmt_vec_info_vec is called at 
the start of vectorize_loops, while stmt_vec_info_vec is not empty. I 
traced this back to gather_scalar_reduction, where we call 
init_stmt_vec_info_vec, but we skip free_stmt_vec_info_vec if we take 
the early-out for simple_loop_info == NULL.

This patch fixes the ICE by making sure we always call 
free_stmt_vec_info_vec in gather_scalar_reduction.

Passes cc1/f951 rebuild and autopar testing.

OK for stage3 trunk if bootstrap and regtest succeeds?

Thanks,
- Tom

[-- Attachment #2: 0001-Always-call-free_stmt_vec_info_vec-in-gather_scalar_reductions.patch --]
[-- Type: text/x-patch, Size: 2165 bytes --]

Always call free_stmt_vec_info_vec in gather_scalar_reductions

2015-11-20  Tom de Vries  <tom@codesourcery.com>

	PR tree-optimization/68460
	* tree-parloops.c (gather_scalar_reductions): Also call
	free_stmt_vec_info_vec if simple_loop_info == NULL.

	* gcc.dg/autopar/pr68460.c: New test.

---
 gcc/testsuite/gcc.dg/autopar/pr68460.c | 35 ++++++++++++++++++++++++++++++++++
 gcc/tree-parloops.c                    |  6 +++++-
 2 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/autopar/pr68460.c b/gcc/testsuite/gcc.dg/autopar/pr68460.c
new file mode 100644
index 0000000..0c00065
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/autopar/pr68460.c
@@ -0,0 +1,35 @@
+/* { dg-do "compile" } */
+/* { dg-options "-O -ftree-parallelize-loops=2 -ftree-vectorize -fno-tree-ch -fno-tree-dominator-opts" } */
+
+void abort (void);
+
+int d[1024], e[1024];
+
+int
+foo (void)
+{
+  int s = 0;
+  int i;
+
+  for (i = 0; i < 1024; i++)
+    s += d[i] - e[i];
+
+  return s;
+}
+
+int
+main ()
+{
+  int i;
+
+  for (i = 0; i < 1024; i++)
+    {
+      d[i] = i * 2;
+      e[i] = i;
+    }
+
+  if (foo () != 1023 * 1024 / 2)
+    abort ();
+
+  return 0;
+}
diff --git a/gcc/tree-parloops.c b/gcc/tree-parloops.c
index 8d7912d..85cc78d 100644
--- a/gcc/tree-parloops.c
+++ b/gcc/tree-parloops.c
@@ -2433,7 +2433,7 @@ gather_scalar_reductions (loop_p loop, reduction_info_table_type *reduction_list
 
   simple_loop_info = vect_analyze_loop_form (loop);
   if (simple_loop_info == NULL)
-    return;
+    goto gather_done;
 
   for (gsi = gsi_start_phis (loop->header); !gsi_end_p (gsi); gsi_next (&gsi))
     {
@@ -2492,9 +2492,13 @@ gather_scalar_reductions (loop_p loop, reduction_info_table_type *reduction_list
   destroy_loop_vec_info (simple_loop_info, true);
   destroy_loop_vec_info (simple_inner_loop_info, true);
 
+ gather_done:
   /* Release the claim on gimple_uid.  */
   free_stmt_vec_info_vec ();
 
+  if (reduction_list->elements () == 0)
+    return;
+
   /* As gimple_uid is used by the vectorizer in between vect_analyze_loop_form
      and free_stmt_vec_info_vec, we can set gimple_uid of reduc_phi stmts only
      now.  */

Re: [PATCH, PR68460] Always call free_stmt_vec_info_vec in gather_scalar_reductions

[Richard Biener]

On Fri, Nov 20, 2015 at 4:57 PM, Tom de Vries <Tom_deVries@mentor.com> wrote:
> [ was: Re: [PATCH] Fix parloops gimple_uid usage ]
>
> On 09/10/15 23:09, Tom de Vries wrote:
>>
>> @@ -2392,6 +2397,9 @@ gather_scalar_reductions (loop_p loop,
>> reduction_info_table_type *reduction_list
>>     loop_vec_info simple_inner_loop_info = NULL;
>>     bool allow_double_reduc = true;
>>
>> +  if (!stmt_vec_info_vec.exists ())
>> +    init_stmt_vec_info_vec ();
>> +
>>     simple_loop_info = vect_analyze_loop_form (loop);
>>     if (simple_loop_info == NULL)
>>       return;
>> @@ -2453,9 +2461,16 @@ gather_scalar_reductions (loop_p loop,
>> reduction_info_table_type *reduction_list
>>     destroy_loop_vec_info (simple_loop_info, true);
>>     destroy_loop_vec_info (simple_inner_loop_info, true);
>>
>> +  /* Release the claim on gimple_uid.  */
>> +  free_stmt_vec_info_vec ();
>> +
>
>
> With the src/libgomp/testsuite/libgomp.c/pr46886.c testcase, compiled in
> addition with -ftree-vectorize, I ran into an ICE:
> ...
> src/libgomp/testsuite/libgomp.c/pr46886.c:8:5: internal compiler error: in
> init_stmt_vec_info_vec, at tree-vect-stmts.c:8250
>  int foo (void)
>      ^~~
>
> 0x1196082 init_stmt_vec_info_vec()
>         src/gcc/tree-vect-stmts.c:8250
> 0x11c3ed4 vectorize_loops()
>         src/gcc/tree-vectorizer.c:510
> 0x10a7ea5 execute
>         src/gcc/tree-ssa-loop.c:276
> ...
>
> The ICE is caused by the fact that init_stmt_vec_info_vec is called at the
> start of vectorize_loops, while stmt_vec_info_vec is not empty. I traced
> this back to gather_scalar_reduction, where we call init_stmt_vec_info_vec,
> but we skip free_stmt_vec_info_vec if we take the early-out for
> simple_loop_info == NULL.
>
> This patch fixes the ICE by making sure we always call
> free_stmt_vec_info_vec in gather_scalar_reduction.
>
> Passes cc1/f951 rebuild and autopar testing.
>
> OK for stage3 trunk if bootstrap and regtest succeeds?

Ok.

Richard.

> Thanks,
> - Tom