Update gcc.target/powerpc/pr92132-fp test for power7 and older

Message ID 024e90efdb560109b432f8ff70af7f90e9dc10e2.camel@vnet.ibm.com
State New
Headers show
Series
  • Update gcc.target/powerpc/pr92132-fp test for power7 and older
Related show

Commit Message

will schmidt Feb. 13, 2020, 10:41 p.m.
Hi,
  Attempting to clean up some more testcase failures.
This test in particular exercises the -ftree-vectorize
option, and by inspection I see this fails out with assorted
"conversion not supported by target" messages on power7 and
earlier systems.

Thus, this would limits the scan-dump check of "LOOP VECTORIZED" to
those targets supporting power8 vector support.
The testcase itself otherwise runs fine, so limiting the test
itself seems unnecessary.

OK for master?

Thanks,
-Will

[testsuite]
    * gcc.target/powerpc/pr92132-fp-1.c: Specify target for scan-dump check.

Comments

Segher Boessenkool Feb. 13, 2020, 11:23 p.m. | #1
On Thu, Feb 13, 2020 at 04:41:09PM -0600, will schmidt wrote:
>   Attempting to clean up some more testcase failures.

> This test in particular exercises the -ftree-vectorize

> option, and by inspection I see this fails out with assorted

> "conversion not supported by target" messages on power7 and

> earlier systems.

> 

> Thus, this would limits the scan-dump check of "LOOP VECTORIZED" to

> those targets supporting power8 vector support.

> The testcase itself otherwise runs fine, so limiting the test

> itself seems unnecessary.


> -/* { dg-final { scan-tree-dump-times "LOOP VECTORIZED" 14 "vect" } } */

> +/* { dg-final { scan-tree-dump-times "LOOP VECTORIZED" 14 "vect" { target p8vector_hw } } } */


That actually checks if the hardware is p8 or later, while what you care
about is what options are compiled with.  Say, if running on a p8 but
compiling for a p7 this will fail?


Segher
will schmidt Feb. 17, 2020, 8:48 p.m. | #2
On Thu, 2020-02-13 at 17:23 -0600, Segher Boessenkool wrote:
> On Thu, Feb 13, 2020 at 04:41:09PM -0600, will schmidt wrote:

> >   Attempting to clean up some more testcase failures.

> > This test in particular exercises the -ftree-vectorize

> > option, and by inspection I see this fails out with assorted

> > "conversion not supported by target" messages on power7 and

> > earlier systems.

> > 

> > Thus, this would limits the scan-dump check of "LOOP VECTORIZED" to

> > those targets supporting power8 vector support.

> > The testcase itself otherwise runs fine, so limiting the test

> > itself seems unnecessary.

> > -/* { dg-final { scan-tree-dump-times "LOOP VECTORIZED" 14 "vect" }

> > } */

> > +/* { dg-final { scan-tree-dump-times "LOOP VECTORIZED" 14 "vect" {

> > target p8vector_hw } } } */

> 

> That actually checks if the hardware is p8 or later, while what you

> care

> about is what options are compiled with.  Say, if running on a p8 but

> compiling for a p7 this will fail?


Right...

I did some experimentation and havn't come up with anything I'm
completely satisfied with.   The powerpc_p8vector_ok check doesn't
fail out like I'd expect it to on a power7 target.

Ok, so it appears check_effective_target_powerpc_p8vector_ok () inserts
a "-mpower8-vector" option as part of it's test, so as long as the
compiler on a power7 system is able to generate power8 code, that
power8-vector check will pass, even if we have not otherwise indicated
power8 in our test incantation.

I'll think on this one some more...
thanks
-Will


> 

> 

> Segher
Segher Boessenkool Feb. 23, 2020, 12:15 a.m. | #3
On Mon, Feb 17, 2020 at 02:48:20PM -0600, will schmidt wrote:
> On Thu, 2020-02-13 at 17:23 -0600, Segher Boessenkool wrote:

> > On Thu, Feb 13, 2020 at 04:41:09PM -0600, will schmidt wrote:

> > > -/* { dg-final { scan-tree-dump-times "LOOP VECTORIZED" 14 "vect" }

> > > } */

> > > +/* { dg-final { scan-tree-dump-times "LOOP VECTORIZED" 14 "vect" {

> > > target p8vector_hw } } } */

> > 

> > That actually checks if the hardware is p8 or later, while what you

> > care

> > about is what options are compiled with.  Say, if running on a p8 but

> > compiling for a p7 this will fail?

> 

> Right...

> 

> I did some experimentation and havn't come up with anything I'm

> completely satisfied with.   The powerpc_p8vector_ok check doesn't

> fail out like I'd expect it to on a power7 target.


What we usually do is duplicate the test, run one for p7, and the other
for p8.  This isn't nice at all.

> Ok, so it appears check_effective_target_powerpc_p8vector_ok () inserts

> a "-mpower8-vector" option as part of it's test, so as long as the

> compiler on a power7 system is able to generate power8 code, that

> power8-vector check will pass, even if we have not otherwise indicated

> power8 in our test incantation.


Yes, that is what the *_ok mean: whether we can compile code for that
target.  This isn't usually useful at all.

> I'll think on this one some more...


If the test can be disabled at the source code level, there are _ARCH_PWR8
and friends.  Maybe we want some dejagnu effective targets that just test
some of those defines?


Segher
will schmidt Feb. 25, 2020, 11:02 p.m. | #4
On Sat, 2020-02-22 at 18:15 -0600, Segher Boessenkool wrote:
> On Mon, Feb 17, 2020 at 02:48:20PM -0600, will schmidt wrote:

> > On Thu, 2020-02-13 at 17:23 -0600, Segher Boessenkool wrote:

> > > On Thu, Feb 13, 2020 at 04:41:09PM -0600, will schmidt wrote:

> > > > -/* { dg-final { scan-tree-dump-times "LOOP VECTORIZED" 14

> > > > "vect" }

> > > > } */

> > > > +/* { dg-final { scan-tree-dump-times "LOOP VECTORIZED" 14

> > > > "vect" {

> > > > target p8vector_hw } } } */

> > > 

> > > That actually checks if the hardware is p8 or later, while what

> > > you

> > > care

> > > about is what options are compiled with.  Say, if running on a p8

> > > but

> > > compiling for a p7 this will fail?

> > 

> > Right...

> > 

> > I did some experimentation and havn't come up with anything I'm

> > completely satisfied with.   The powerpc_p8vector_ok check doesn't

> > fail out like I'd expect it to on a power7 target.

> 

> What we usually do is duplicate the test, run one for p7, and the

> other

> for p8.  This isn't nice at all.

> 

> > Ok, so it appears check_effective_target_powerpc_p8vector_ok ()

> > inserts

> > a "-mpower8-vector" option as part of it's test, so as long as the

> > compiler on a power7 system is able to generate power8 code, that

> > power8-vector check will pass, even if we have not otherwise

> > indicated

> > power8 in our test incantation.

> 

> Yes, that is what the *_ok mean: whether we can compile code for that

> target.  This isn't usually useful at all.

> 

> > I'll think on this one some more...

> 

> If the test can be disabled at the source code level, there are

> _ARCH_PWR8

> and friends.  Maybe we want some dejagnu effective targets that just

> test

> some of those defines?


Yup, I've sorted out some changes that work.  It's now more of a
target-supports.exp change, versus just touching this testcase, so I'm
posting in a separate thread, momentarily.

Thanks
-Will

> 

> 

> Segher

Patch

diff --git a/gcc/testsuite/gcc.target/powerpc/pr92132-fp-1.c b/gcc/testsuite/gcc.target/powerpc/pr92132-fp-1.c
index 1023e8c..2014896 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr92132-fp-1.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr92132-fp-1.c
@@ -292,6 +292,6 @@  main (void)
     abort ();
 
   return 0;
 }
 
-/* { dg-final { scan-tree-dump-times "LOOP VECTORIZED" 14 "vect" } } */
+/* { dg-final { scan-tree-dump-times "LOOP VECTORIZED" 14 "vect" { target p8vector_hw } } } */