rs6000/test: Adjust pr104992.c with vect_int_mod [PR106516]

  Hi,

As PR106516 shows, we can get unexpected gimple outputs for
function thud on some target which supports modulus operation
for vector int.  This patch introduces one effective target
vect_int_mod for it, then adjusts the test case with it.

Tested on x86_64-redhat-linux and powerpc64{,le}-linux-gnu,
especially powerpc64le Power10.

Is it ok for trunk?

BR,
Kewen
-----
	PR testsuite/106516

gcc/testsuite/ChangeLog:

	* gcc.dg/pr104992.c: Adjust with vect_int_mod.
	* lib/target-supports.exp (check_effective_target_vect_int_mod): New
	proc for effective target vect_int_mod.
---
 gcc/testsuite/gcc.dg/pr104992.c       | 3 ++-
 gcc/testsuite/lib/target-supports.exp | 8 ++++++++
 2 files changed, 10 insertions(+), 1 deletion(-)

--
2.27.0
  

Hi,

I assumed the generic part introducing check_effective_target_vect_int_mod
needs the approval from global maintainers.

So gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600191.html

BR,
Kewen

on 2022/8/24 16:17, Kewen.Lin via Gcc-patches wrote:
> Hi,
> 
> As PR106516 shows, we can get unexpected gimple outputs for
> function thud on some target which supports modulus operation
> for vector int.  This patch introduces one effective target
> vect_int_mod for it, then adjusts the test case with it.
> 
> Tested on x86_64-redhat-linux and powerpc64{,le}-linux-gnu,
> especially powerpc64le Power10.
> 
> Is it ok for trunk?
> 
> BR,
> Kewen
> -----
> 	PR testsuite/106516
> 
> gcc/testsuite/ChangeLog:
> 
> 	* gcc.dg/pr104992.c: Adjust with vect_int_mod.
> 	* lib/target-supports.exp (check_effective_target_vect_int_mod): New
> 	proc for effective target vect_int_mod.
> ---
>  gcc/testsuite/gcc.dg/pr104992.c       | 3 ++-
>  gcc/testsuite/lib/target-supports.exp | 8 ++++++++
>  2 files changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/testsuite/gcc.dg/pr104992.c b/gcc/testsuite/gcc.dg/pr104992.c
> index 217c89a458c..82f8c75559c 100644
> --- a/gcc/testsuite/gcc.dg/pr104992.c
> +++ b/gcc/testsuite/gcc.dg/pr104992.c
> @@ -54,4 +54,5 @@ __attribute__((noipa)) unsigned waldo (unsigned x, unsigned y, unsigned z) {
>      return x / y * z == x;
>  }
> 
> -/* { dg-final {scan-tree-dump-times " % " 9 "optimized" } } */
> +/* { dg-final { scan-tree-dump-times " % " 9 "optimized" { target { ! vect_int_mod } } } } */
> +/* { dg-final { scan-tree-dump-times " % " 6 "optimized" { target vect_int_mod } } } */
> diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
> index 04a2a8e8659..a4bdd23bed0 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -8239,6 +8239,14 @@ proc check_effective_target_vect_long_mult { } {
>      return $answer
>  }
> 
> +# Return 1 if the target supports vector int modulus, 0 otherwise.
> +
> +proc check_effective_target_vect_int_mod { } {
> +    return [check_cached_effective_target_indexed vect_int_mod {
> +      expr { [istarget powerpc*-*-*]
> +	     && [check_effective_target_power10_ok] }}]
> +}
> +
>  # Return 1 if the target supports vector even/odd elements extraction, 0 otherwise.
> 
>  proc check_effective_target_vect_extract_even_odd { } {
> --
> 2.27.0
  

Hi!

On Wed, Aug 24, 2022 at 04:17:55PM +0800, Kewen.Lin wrote:
> As PR106516 shows, we can get unexpected gimple outputs for
> function thud on some target which supports modulus operation
> for vector int.  This patch introduces one effective target
> vect_int_mod for it, then adjusts the test case with it.

> +# Return 1 if the target supports vector int modulus, 0 otherwise.
> +
> +proc check_effective_target_vect_int_mod { } {
> +    return [check_cached_effective_target_indexed vect_int_mod {
> +      expr { [istarget powerpc*-*-*]
> +	     && [check_effective_target_power10_ok] }}]
> +}

power10_ok does not mean the vmod[su][wdq] instructions will be
generated.  You need to test if we have -mcpu=power10 or such, so,
check_effective_target_has_arch_pwr10 .

<X>_ok tests if it is okay to enable <X>.  <X>_hw tests if the hardware
can do <X>.  has_arch_<X> tests if the compiler is asked to generate
code for <X> (which is reflected in the _ARCH_* preprocessor symbols,
hence the name).

Okay for trunk with the correct check_effective_target_* .  Thanks!


Segher
  

On Wed, Sep 28, 2022 at 01:35:09PM +0800, Kewen.Lin wrote:
> I assumed the generic part introducing check_effective_target_vect_int_mod
> needs the approval from global maintainers.

Target-specific testsuite changes can be approved by target maintainers.
Currently this can be considered target-specific (since we are the only
one implementing it), so :-)  I know it is borderline.


Segher
  

Hi Segher!

on 2022/9/28 22:55, Segher Boessenkool wrote:
> Hi!
> 
> On Wed, Aug 24, 2022 at 04:17:55PM +0800, Kewen.Lin wrote:
>> As PR106516 shows, we can get unexpected gimple outputs for
>> function thud on some target which supports modulus operation
>> for vector int.  This patch introduces one effective target
>> vect_int_mod for it, then adjusts the test case with it.
> 
>> +# Return 1 if the target supports vector int modulus, 0 otherwise.
>> +
>> +proc check_effective_target_vect_int_mod { } {
>> +    return [check_cached_effective_target_indexed vect_int_mod {
>> +      expr { [istarget powerpc*-*-*]
>> +	     && [check_effective_target_power10_ok] }}]
>> +}
> 
> power10_ok does not mean the vmod[su][wdq] instructions will be
> generated.  You need to test if we have -mcpu=power10 or such, so,
> check_effective_target_has_arch_pwr10 .

Indeed, the context is different from those cases in gcc.target/powerpc
which have -mdejagnu-cpu=power10 normally.  Thanks for catching and 
the correction!

> 
> <X>_ok tests if it is okay to enable <X>.  <X>_hw tests if the hardware
> can do <X>.  has_arch_<X> tests if the compiler is asked to generate
> code for <X> (which is reflected in the _ARCH_* preprocessor symbols,
> hence the name).
> 
> Okay for trunk with the correct check_effective_target_* .  Thanks!
> 

Thanks, re-tested as before, committed in r13-2983.

BR,
Kewen