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, 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