| Message ID | 024e90efdb560109b432f8ff70af7f90e9dc10e2.camel@vnet.ibm.com |
|---|---|
| State | New |
| Headers | show |
| Series | Update gcc.target/powerpc/pr92132-fp test for power7 and older | expand |
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
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
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
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
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 } } } */
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.