On Thu, 28 Jun 2018, Christophe Lyon wrote:
> On Fri, 22 Jun 2018 at 12:52, Richard Biener <rguent...@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 <rguent...@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;
}
