public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH] rs6000/test: Adjust pr104992.c with vect_int_mod [PR106516]
@ 2022-08-24  8:17 Kewen.Lin
  2022-09-28  5:35 ` PING^1 " Kewen.Lin
  2022-09-28 14:55 ` Segher Boessenkool
  0 siblings, 2 replies; 5+ messages in thread
From: Kewen.Lin @ 2022-08-24  8:17 UTC (permalink / raw)
  To: GCC Patches
  Cc: Segher Boessenkool, Richard Biener, David Edelsohn, Richard Sandiford

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* PING^1 [PATCH] rs6000/test: Adjust pr104992.c with vect_int_mod [PR106516]
  2022-08-24  8:17 [PATCH] rs6000/test: Adjust pr104992.c with vect_int_mod [PR106516] Kewen.Lin
@ 2022-09-28  5:35 ` Kewen.Lin
  2022-09-28 15:00   ` Segher Boessenkool
  2022-09-28 14:55 ` Segher Boessenkool
  1 sibling, 1 reply; 5+ messages in thread
From: Kewen.Lin @ 2022-09-28  5:35 UTC (permalink / raw)
  To: GCC Patches
  Cc: Richard Sandiford, David Edelsohn, Segher Boessenkool, Richard Biener

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] rs6000/test: Adjust pr104992.c with vect_int_mod [PR106516]
  2022-08-24  8:17 [PATCH] rs6000/test: Adjust pr104992.c with vect_int_mod [PR106516] Kewen.Lin
  2022-09-28  5:35 ` PING^1 " Kewen.Lin
@ 2022-09-28 14:55 ` Segher Boessenkool
  2022-09-30 12:25   ` Kewen.Lin
  1 sibling, 1 reply; 5+ messages in thread
From: Segher Boessenkool @ 2022-09-28 14:55 UTC (permalink / raw)
  To: Kewen.Lin; +Cc: GCC Patches, Richard Biener, David Edelsohn, Richard Sandiford

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: PING^1 [PATCH] rs6000/test: Adjust pr104992.c with vect_int_mod [PR106516]
  2022-09-28  5:35 ` PING^1 " Kewen.Lin
@ 2022-09-28 15:00   ` Segher Boessenkool
  0 siblings, 0 replies; 5+ messages in thread
From: Segher Boessenkool @ 2022-09-28 15:00 UTC (permalink / raw)
  To: Kewen.Lin; +Cc: GCC Patches, Richard Sandiford, David Edelsohn, Richard Biener

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] rs6000/test: Adjust pr104992.c with vect_int_mod [PR106516]
  2022-09-28 14:55 ` Segher Boessenkool
@ 2022-09-30 12:25   ` Kewen.Lin
  0 siblings, 0 replies; 5+ messages in thread
From: Kewen.Lin @ 2022-09-30 12:25 UTC (permalink / raw)
  To: Segher Boessenkool
  Cc: GCC Patches, Richard Biener, David Edelsohn, Richard Sandiford

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2022-09-30 12:25 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-24  8:17 [PATCH] rs6000/test: Adjust pr104992.c with vect_int_mod [PR106516] Kewen.Lin
2022-09-28  5:35 ` PING^1 " Kewen.Lin
2022-09-28 15:00   ` Segher Boessenkool
2022-09-28 14:55 ` Segher Boessenkool
2022-09-30 12:25   ` Kewen.Lin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).