[PATCH][2/3] Share dataref and dependence analysis for multi-vector size vectorization

Richard Biener rguenther@suse.de
Fri Jun 29 07:39:00 GMT 2018


On Thu, 28 Jun 2018, Christophe Lyon wrote:

> On Fri, 22 Jun 2018 at 12:52, Richard Biener <rguenther@suse.de> wrote:
> >
> >
> > This is the main part to make considering multiple vector sizes based on
> > costs less compile-time costly.  It shares dataref analysis and
> > dependence analysis for loop vectorization (BB vectorization is only
> > adjusted to comply with the new APIs sofar).
> >
> > Sharing means that DRs (and of course DDRs) may not be modified during
> > vectorization analysis which means splitting out dataref_aux from
> > dangling from dr->aux to separate copies in the DR_STMTs vinfo.
> > I've put measures in place that assure that DRs are not modified
> > (because they were) but refrained from doing the same for DDRs
> > (because I didn't run into any issues).
> >
> > The sharing then is accomplished by moving the dataref and
> > ddr array as well as the dependent loop-nest array into a
> > separate structure with bigger lifetime than vinfo and appropriately
> > link to it from there.
> >
> > Bootstrapped on x86_64-unknown-linux-gnu (together with [1/3]),
> > testing in progress.
> >
> 
> Hi Richard,
> 
> This you committed this patch (r262009) I've noticed a regression on
> aarch64 and arm,
> and I think it's also present on x86 according to gcc-testresults:
> FAIL:    gcc.dg/params/blocksort-part.c -O3 --param
> loop-max-datarefs-for-datadeps=0 (test for excess errors)
> FAIL:gcc.dg/params/blocksort-part.c -O3 --param
> loop-max-datarefs-for-datadeps=0 (internal compiler error)
> 
> gcc.log says:
> 
> during GIMPLE pass: vect
> /gcc/testsuite/gcc.dg/params/blocksort-part.c: In function 'fallbackQSort3':
> /gcc/testsuite/gcc.dg/params/blocksort-part.c:116:6: internal compiler
> error: Segmentation fault
> 0xbef215 crash_signal
>         /gcc/toplev.c:324
> 0x14715cc gimple_uid
>         /gcc/tree-vectorizer.h:1043
> 0x14715cc vinfo_for_stmt
>         /gcc/tree-vectorizer.h:1043
> 0x14715cc vect_dr_stmt
>         /gcc/tree-vectorizer.h:1331
> 0x14715cc vect_analyze_data_ref_dependence
>         /gcc/tree-vect-data-refs.c:297
> 0x14715cc vect_analyze_data_ref_dependences(_loop_vec_info*, unsigned int*)
>         /gcc/tree-vect-data-refs.c:593
> 0xecabb8 vect_analyze_loop_2
>         /gcc/tree-vect-loop.c:1910
> 0xecc70c vect_analyze_loop(loop*, _loop_vec_info*, vec_info_shared*)
>         /gcc/tree-vect-loop.c:2337
> 0xeec188 try_vectorize_loop_1
>         /gcc/tree-vectorizer.c:705
> 0xeed512 vectorize_loops()
>         /gcc/tree-vectorizer.c:918

I am testing the following.

Richard.

2018-06-29  Richard Biener  <rguenther@suse.de>

	* tree-vect-data-refs.c (vect_analyze_data_ref_dependences): Assert
	compute_all_dependences succeeds.
	* tree-vect-loop.c (vect_get_datarefs_in_loop): Fail early if we
	exceed --param loop-max-datarefs-for-datadeps.

diff --git a/gcc/tree-vect-data-refs.c b/gcc/tree-vect-data-refs.c
index 9f848fefd1e..63429a34bf2 100644
--- a/gcc/tree-vect-data-refs.c
+++ b/gcc/tree-vect-data-refs.c
@@ -575,10 +575,11 @@ vect_analyze_data_ref_dependences (loop_vec_info loop_vinfo,
 		 * LOOP_VINFO_DATAREFS (loop_vinfo).length ());
       /* We need read-read dependences to compute
 	 STMT_VINFO_SAME_ALIGN_REFS.  */
-      if (!compute_all_dependences (LOOP_VINFO_DATAREFS (loop_vinfo),
-				    &LOOP_VINFO_DDRS (loop_vinfo),
-				    LOOP_VINFO_LOOP_NEST (loop_vinfo), true))
-	return false;
+      bool res = compute_all_dependences (LOOP_VINFO_DATAREFS (loop_vinfo),
+					  &LOOP_VINFO_DDRS (loop_vinfo),
+					  LOOP_VINFO_LOOP_NEST (loop_vinfo),
+					  true);
+      gcc_assert (res);
     }
 
   LOOP_VINFO_NO_DATA_DEPENDENCIES (loop_vinfo) = true;
diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index cd19fe6fbab..8d6ee648b35 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -1808,6 +1808,11 @@ vect_get_datarefs_in_loop (loop_p loop, basic_block *bbs,
 	      }
 	    return false;
 	  }
+	/* If dependence analysis will give up due to the limit on the
+	   number of datarefs stop here and fail fatally.  */
+	if (datarefs->length ()
+	    > (unsigned)PARAM_VALUE (PARAM_LOOP_MAX_DATAREFS_FOR_DATADEPS))
+	  return false;
       }
   return true;
 }



More information about the Gcc-patches mailing list