[testsuite] XFAIL gcc.dg/tree-ssa/ssa-dom-cse-2.c on non-NEON arm targets

Message ID 5A686E84.4070409@foss.arm.com
State New
Headers show
Series
  • [testsuite] XFAIL gcc.dg/tree-ssa/ssa-dom-cse-2.c on non-NEON arm targets
Related show

Commit Message

Kyrill Tkachov Jan. 24, 2018, 11:31 a.m.
Hi all,

This test fails to optimise away the PLUS reduction in the loop on arm targets when vectorisation
is not enabled due to absence of SIMD instructions.
 From reading the logs and the PR I gather that the presence or absence of SIMD affects the passing of this test
on other targets as well, as evidenced by the long list of xfail targets.
This list looks quite unwieldy to me, but here is a patch adding non-NEON arm to that list.
Is this ok?

Or should we always force -mfpu=neon for arm targets instead? That's what we do for System Z,
but from a purist perspective the loop has nothing vector-specific in it so a compiler should be
able to reduce it regardless...

Thanks,
Kyrill

2018-01-24  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>

     * gcc.dg/tree-ssa/ssa-dom-cse-2.c: XFAIL on !arm_neon arm targets.

Comments

Jeff Law Jan. 30, 2018, 6 a.m. | #1
On 01/24/2018 04:31 AM, Kyrill Tkachov wrote:
> Hi all,

> 

> This test fails to optimise away the PLUS reduction in the loop on arm

> targets when vectorisation

> is not enabled due to absence of SIMD instructions.

> From reading the logs and the PR I gather that the presence or absence

> of SIMD affects the passing of this test

> on other targets as well, as evidenced by the long list of xfail targets.

> This list looks quite unwieldy to me, but here is a patch adding

> non-NEON arm to that list.

> Is this ok?

> 

> Or should we always force -mfpu=neon for arm targets instead? That's

> what we do for System Z,

> but from a purist perspective the loop has nothing vector-specific in it

> so a compiler should be

> able to reduce it regardless...

> 

> Thanks,

> Kyrill

> 

> 2018-01-24  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>

> 

>     * gcc.dg/tree-ssa/ssa-dom-cse-2.c: XFAIL on !arm_neon arm targets.

It does look rather unwieldy.  I wonder if we would be better off
manually unrolling the loop and conditionalizing it on some kind of
vector support.

But in the immediate term, adding another xfailed target is fine.

jeff

Patch

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-cse-2.c b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-cse-2.c
index 7e77a6a0a226262541674bec1d7bdf081e916215..8606969e0940c36d6ba23f8e213b2fd4f5c1d52d 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-cse-2.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-cse-2.c
@@ -25,4 +25,4 @@  foo ()
    but the loop reads only one element at a time, and DOM cannot resolve these.
    The same happens on powerpc depending on the SIMD support available.  */
 
-/* { dg-final { scan-tree-dump "return 28;" "optimized" { xfail { { alpha*-*-* hppa*64*-*-* nvptx*-*-* } || { { lp64 && { powerpc*-*-* sparc*-*-* riscv*-*-* } } || aarch64_sve } } } } } */
+/* { dg-final { scan-tree-dump "return 28;" "optimized" { xfail { { alpha*-*-* hppa*64*-*-* nvptx*-*-* } || { { { lp64 && { powerpc*-*-* sparc*-*-* riscv*-*-* } } || aarch64_sve } || { arm*-*-* && { ! arm_neon } } } } } } } */