On Wed, 3 Nov 2021, Jiufu Guo wrote:
> Richard Biener <rguent...@suse.de> writes:
>
> > On Mon, 1 Nov 2021, Jiufu Guo wrote:
> >
> >> PR101145 is supporting if the number of iterations can be calculated
> >> for the 'until wrap' condition. Current test cases are checking if
> >> the loop can be vectorized, if a loop can be vectorized then the number
> >> of interations is known. While it would be better to check the loop's
> >> number of iterations directly. This patch updates the test cases
> >> accordingly.
> >>
> >> Bootstrap and regtest pass on ppc,ppc64le and x86_64.
> >> Is this ok for trunk?
> >
> > Not sure - the motivation was to make the loop vectorizable so
> > a vectorized check is strictly more powerful. What's the problem
> > with the existing test?
>
> Thanks, Richard!
>
> The problem of current tests is that some targets do not support
> vectorization on some types, like "vector(8) unsigned char" on
> Solaris/SPARC, "vector long long" on Power7:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102946
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102069
>
> On those targets, the "number of iterations" was calculated for
> the loops in the test cases, while the loops are not vectorized.
I see, but can you add appropriate target selectors for the
vectorization then and keep those scans? I'm not sure why you
return the final IV value from the functions rather than
testing correct data in a[], that will complicate selecting the
targets that can vectorize things. There is vect_char_add and
vect_long_long you could require in addition to vect_int.
> The functionality of the patch in PR101145 is to enhance
> number_of_iterations_cond to calculate the "# of iterations" for
> the condition like 'while (i-- < n) or (i++ > n)'.
> When I add cases pr101145*.c, vectorization is used test. At that
> time, I also think checking vectorization would be more strict,
> since the goal of computing '# of iterations' is to enable other
> optimizations, like 'vectorization'.
>
> While, I'm wondering it may be better to check the "# of iterations"
> directly, because the number of iterations is still useful even
> loops are not vectorized.
>
> BR,
> Jiufu
>
> >
> > Richard.
> >
> >> BR,
> >> Jiufu
> >>
> >> gcc/testsuite/ChangeLog:
> >>
> >> * gcc.dg/vect/pr101145_1.c: Update case.
> >> * gcc.dg/vect/pr101145_2.c: Update case.
> >> * gcc.dg/vect/pr101145_3.c: Update case.
> >>
> >> ---
> >> gcc/testsuite/gcc.dg/vect/pr101145_1.c | 2 +-
> >> gcc/testsuite/gcc.dg/vect/pr101145_2.c | 2 +-
> >> gcc/testsuite/gcc.dg/vect/pr101145_3.c | 2 +-
> >> 3 files changed, 3 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/gcc/testsuite/gcc.dg/vect/pr101145_1.c
> >> b/gcc/testsuite/gcc.dg/vect/pr101145_1.c
> >> index 9332b2c4257..13a89fa6863 100644
> >> --- a/gcc/testsuite/gcc.dg/vect/pr101145_1.c
> >> +++ b/gcc/testsuite/gcc.dg/vect/pr101145_1.c
> >> @@ -10,4 +10,4 @@
> >>
> >> #include "pr101145.inc"
> >>
> >> -/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 2 "vect" } } */
> >> +/* { dg-final { scan-tree-dump-times "Symbolic number of iterations is" 2
> >> "vect" } } */
> >> diff --git a/gcc/testsuite/gcc.dg/vect/pr101145_2.c
> >> b/gcc/testsuite/gcc.dg/vect/pr101145_2.c
> >> index fa2c6be689a..5265491b98d 100644
> >> --- a/gcc/testsuite/gcc.dg/vect/pr101145_2.c
> >> +++ b/gcc/testsuite/gcc.dg/vect/pr101145_2.c
> >> @@ -10,4 +10,4 @@
> >>
> >> #include "pr101145.inc"
> >>
> >> -/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 2 "vect" } } */
> >> +/* { dg-final { scan-tree-dump-times "Symbolic number of iterations is" 2
> >> "vect" } } */
> >> diff --git a/gcc/testsuite/gcc.dg/vect/pr101145_3.c
> >> b/gcc/testsuite/gcc.dg/vect/pr101145_3.c
> >> index 9f43c82593f..ffda26cf0bc 100644
> >> --- a/gcc/testsuite/gcc.dg/vect/pr101145_3.c
> >> +++ b/gcc/testsuite/gcc.dg/vect/pr101145_3.c
> >> @@ -10,4 +10,4 @@
> >>
> >> #include "pr101145.inc"
> >>
> >> -/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 2 "vect" } } */
> >> +/* { dg-final { scan-tree-dump-times "Symbolic number of iterations is" 2
> >> "vect" } } */
> >>
>
--
Richard Biener <rguent...@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Ivo Totev; HRB 36809 (AG Nuernberg)
