Check number of iterations for test cases pr101145

  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?

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(-)
  

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?

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 <rguenther@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.

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" } } */
>>
  

On Wed, 3 Nov 2021, Jiufu Guo wrote:

> Richard Biener <rguenther@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 <rguenther@suse.de> writes:

> On Wed, 3 Nov 2021, Jiufu Guo wrote:
>
>> Richard Biener <rguenther@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.

Hi Richard,

Thanks a lot for your sugguestion! vect_char_add and vect_long_long
would help these cases. I would update accordingly.
One small concern: these cases may not be tested on some platform.

BR,
Jiufu

>
>> 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 <rguenther@suse.de> writes:

> On Wed, 3 Nov 2021, Jiufu Guo wrote:
>
>> Richard Biener <rguenther@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.

Thanks Richard,

The final IV would be the index of last iteration, test test cases
are checking if it is just wrap around max/min of the index type.

I updated the patch accordingly.

BR,
Jiufu


--------------------
[PATCH] Update dg-require-effective-target for pr101145 cases

For test cases pr101145*.c, some types are not able to be
vectorized on some targets. This patch updates
dg-require-effective-target according to test cases.

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..24a9da63e88 100644
--- a/gcc/testsuite/gcc.dg/vect/pr101145_1.c
+++ b/gcc/testsuite/gcc.dg/vect/pr101145_1.c
@@ -1,4 +1,4 @@
-/* { dg-require-effective-target vect_int } */
+/* { dg-require-effective-target vect_char_add } */
 /* { dg-additional-options "-O3" } */
 #define TYPE signed char
 #define MIN -128
diff --git a/gcc/testsuite/gcc.dg/vect/pr101145_2.c b/gcc/testsuite/gcc.dg/vect/pr101145_2.c
index fa2c6be689a..9091f606066 100644
--- a/gcc/testsuite/gcc.dg/vect/pr101145_2.c
+++ b/gcc/testsuite/gcc.dg/vect/pr101145_2.c
@@ -1,4 +1,4 @@
-/* { dg-require-effective-target vect_int } */
+/* { dg-require-effective-target vect_char_add } */
 /* { dg-additional-options "-O3" } */
 #define TYPE unsigned char
 #define MIN 0
diff --git a/gcc/testsuite/gcc.dg/vect/pr101145_3.c b/gcc/testsuite/gcc.dg/vect/pr101145_3.c
index 9f43c82593f..001e5f38a46 100644
--- a/gcc/testsuite/gcc.dg/vect/pr101145_3.c
+++ b/gcc/testsuite/gcc.dg/vect/pr101145_3.c
@@ -1,4 +1,4 @@
-/* { dg-require-effective-target vect_int } */
+/* { dg-require-effective-target vect_long_long } */
 /* { dg-additional-options "-O3" } */
 #define TYPE int *
 #define MIN ((TYPE)0)
  

On Thu, 4 Nov 2021, Jiufu Guo wrote:

> Richard Biener <rguenther@suse.de> writes:
> 
> > On Wed, 3 Nov 2021, Jiufu Guo wrote:
> >
> >> Richard Biener <rguenther@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.
> 
> Thanks Richard,
> 
> The final IV would be the index of last iteration, test test cases
> are checking if it is just wrap around max/min of the index type.
> 
> I updated the patch accordingly.

OK.

Thanks,
Richard.

> BR,
> Jiufu
> 
> 
> --------------------
> [PATCH] Update dg-require-effective-target for pr101145 cases
> 
> For test cases pr101145*.c, some types are not able to be
> vectorized on some targets. This patch updates
> dg-require-effective-target according to test cases.
> 
> 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..24a9da63e88 100644
> --- a/gcc/testsuite/gcc.dg/vect/pr101145_1.c
> +++ b/gcc/testsuite/gcc.dg/vect/pr101145_1.c
> @@ -1,4 +1,4 @@
> -/* { dg-require-effective-target vect_int } */
> +/* { dg-require-effective-target vect_char_add } */
>  /* { dg-additional-options "-O3" } */
>  #define TYPE signed char
>  #define MIN -128
> diff --git a/gcc/testsuite/gcc.dg/vect/pr101145_2.c b/gcc/testsuite/gcc.dg/vect/pr101145_2.c
> index fa2c6be689a..9091f606066 100644
> --- a/gcc/testsuite/gcc.dg/vect/pr101145_2.c
> +++ b/gcc/testsuite/gcc.dg/vect/pr101145_2.c
> @@ -1,4 +1,4 @@
> -/* { dg-require-effective-target vect_int } */
> +/* { dg-require-effective-target vect_char_add } */
>  /* { dg-additional-options "-O3" } */
>  #define TYPE unsigned char
>  #define MIN 0
> diff --git a/gcc/testsuite/gcc.dg/vect/pr101145_3.c b/gcc/testsuite/gcc.dg/vect/pr101145_3.c
> index 9f43c82593f..001e5f38a46 100644
> --- a/gcc/testsuite/gcc.dg/vect/pr101145_3.c
> +++ b/gcc/testsuite/gcc.dg/vect/pr101145_3.c
> @@ -1,4 +1,4 @@
> -/* { dg-require-effective-target vect_int } */
> +/* { dg-require-effective-target vect_long_long } */
>  /* { dg-additional-options "-O3" } */
>  #define TYPE int *
>  #define MIN ((TYPE)0)
>