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

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

[will schmidt]

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.

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 } } } */

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

[Segher Boessenkool]

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

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

[will schmidt]

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

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

[Segher Boessenkool]

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

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

[will schmidt]

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