On 2/28/18 5:01 PM, Segher Boessenkool wrote:
> On Wed, Feb 28, 2018 at 04:51:27PM -0600, Peter Bergner wrote:
>> Doh! I was going to say "why?" since we're xfailing it everywhere, but I
>
> Because you can use a few more words in changelog entries ;-)
>
> "Add xfail." is fine, too. Just "xfail." is unclear.
Ok.
>> So should we go with my original idea above? Or maybe we don't care
>> that we XFAIL on some targets since we're just going to remove the
>> test next release with the removal -maltivec=be?
>
> It would be nice to have clean test results, which is all this patch is
> about anyway, right?
Ok, this XFAILs the test case and shouldn't create any extra noise when
it shouldn't. I also added the comment about no longer counting xxlor
insns. Better?
Peter
PR target/84534
* gcc.target/powerpc/vec-setup-be-long.c: Add dg-xfail-run-if
on powerpc64le*-*-linux*.
* gcc.target/powerpc/vsx-vector-6-le.c: Do not count xxlor's.
* gcc.target/powerpc/vsx-vector-6-le.p9.c: Likewise.
Index: gcc/testsuite/gcc.target/powerpc/vec-setup-be-long.c
===================================================================
--- gcc/testsuite/gcc.target/powerpc/vec-setup-be-long.c (revision
258038)
+++ gcc/testsuite/gcc.target/powerpc/vec-setup-be-long.c (working copy)
@@ -1,4 +1,7 @@
+/* Per PR78303, we are deprecating usage of -maltivec=be on little endian,
+ so XFAIL this test until support is actually removed. */
/* { dg-do run { target { powerpc64le*-*-linux* } } } */
+/* { dg-xfail-run-if "PR78303 and PR84534" { powerpc64le*-*-linux* } } */
/* { dg-require-effective-target vsx_hw } */
/* Disable warnings to squelch deprecation message about -maltivec=be. */
/* { dg-options "-w -O2 -mvsx -maltivec=be" } */
Index: gcc/testsuite/gcc.target/powerpc/vsx-vector-6-le.c
===================================================================
--- gcc/testsuite/gcc.target/powerpc/vsx-vector-6-le.c (revision 258038)
+++ gcc/testsuite/gcc.target/powerpc/vsx-vector-6-le.c (working copy)
@@ -9,7 +9,11 @@
/* { dg-final { scan-assembler-times "xvabsdp" 1 } } */
/* { dg-final { scan-assembler-times "xvadddp" 1 } } */
/* { dg-final { scan-assembler-times "xxlnor" 8 } } */
-/* { dg-final { scan-assembler-times "xxlor" 30 } } */
+/* We generate xxlor instructions for many reasons other than or'ing vector
+ operands or calling __builtin_vec_or(), which means we cannot rely on
+ their usage counts being stable. Therefore, we just ensure at least one
+ xxlor instruction was generated. */
+/* { dg-final { scan-assembler "xxlor" } } */
/* { dg-final { scan-assembler-times "xvcmpeqdp" 5 } } */
/* { dg-final { scan-assembler-times "xvcmpgtdp" 8 } } */
/* { dg-final { scan-assembler-times "xvcmpgedp" 6 } } */
Index: gcc/testsuite/gcc.target/powerpc/vsx-vector-6-le.p9.c
===================================================================
--- gcc/testsuite/gcc.target/powerpc/vsx-vector-6-le.p9.c (revision
258038)
+++ gcc/testsuite/gcc.target/powerpc/vsx-vector-6-le.p9.c (working copy)
@@ -9,7 +9,11 @@
/* { dg-final { scan-assembler-times "xvabsdp" 1 } } */
/* { dg-final { scan-assembler-times "xvadddp" 1 } } */
/* { dg-final { scan-assembler-times "xxlnor" 7 } } */
-/* { dg-final { scan-assembler-times "xxlor" 20 } } */
+/* We generate xxlor instructions for many reasons other than or'ing vector
+ operands or calling __builtin_vec_or(), which means we cannot rely on
+ their usage counts being stable. Therefore, we just ensure at least one
+ xxlor instruction was generated. */
+/* { dg-final { scan-assembler "xxlor" } } */
/* { dg-final { scan-assembler-times "xvcmpeqdp" 5 } } */
/* { dg-final { scan-assembler-times "xvcmpgtdp" 8 } } */
/* { dg-final { scan-assembler-times "xvcmpgedp" 8 } } */
