ARM Neon Tests Failing on non-Neon Target

ARM Neon Tests Failing on non-Neon Target

[Joel Sherrill]

Hi,

I am looking at the arm-rtems test results for the
trunk and noticing that most failures appear to be
for neon tests.

[joel@rtbf64a gcc]$ grep ^FAIL gcc.log.sent  | wc -l
2203
[joel@rtbf64a gcc]$ grep ^FAIL gcc.log.sent | grep /neon/  | wc -l
1986

http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg02780.html

I see that there is an arm_neon_ok check in lib/target-supports.exp
but it only checks that neon code compiles.  It will compile but the
target can't run it.

Any ideas other than a "no_neon" setting in the board file?

-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985

Re: ARM Neon Tests Failing on non-Neon Target

[Joseph S. Myers]

On Thu, 29 Apr 2010, Joel Sherrill wrote:

> Hi,
> 
> I am looking at the arm-rtems test results for the
> trunk and noticing that most failures appear to be
> for neon tests.
> 
> [joel@rtbf64a gcc]$ grep ^FAIL gcc.log.sent  | wc -l
> 2203
> [joel@rtbf64a gcc]$ grep ^FAIL gcc.log.sent | grep /neon/  | wc -l
> 1986
> 
> http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg02780.html
> 
> I see that there is an arm_neon_ok check in lib/target-supports.exp
> but it only checks that neon code compiles.  It will compile but the
> target can't run it.

The vast bulk of NEON tests are compilation-only tests, not execution only 
tests.  Since your failures are generally "test for excess errors" and 
"internal compiler error", that indicates compilation failures that are 
nothing to do with whether your target can run the code; you need to 
investigate the actual errors seen.

It looks like arm-rtems may not be an EABI target.  NEON has probably not 
been tested much if at all for non-EABI targets.

Vectorization tests will already test whether NEON code can be executed on 
the target before trying to execute it.  The arm_neon_hw effective-target 
serves that purpose for tests that genuinely need to execute NEON code.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: ARM Neon Tests Failing on non-Neon Target

[Joel Sherrill]

On 04/29/2010 06:06 PM, Joseph S. Myers wrote:
> On Thu, 29 Apr 2010, Joel Sherrill wrote:
>
>    
>> Hi,
>>
>> I am looking at the arm-rtems test results for the
>> trunk and noticing that most failures appear to be
>> for neon tests.
>>
>> [joel@rtbf64a gcc]$ grep ^FAIL gcc.log.sent  | wc -l
>> 2203
>> [joel@rtbf64a gcc]$ grep ^FAIL gcc.log.sent | grep /neon/  | wc -l
>> 1986
>>
>> http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg02780.html
>>
>> I see that there is an arm_neon_ok check in lib/target-supports.exp
>> but it only checks that neon code compiles.  It will compile but the
>> target can't run it.
>>      
> The vast bulk of NEON tests are compilation-only tests, not execution only
> tests.  Since your failures are generally "test for excess errors" and
> "internal compiler error", that indicates compilation failures that are
> nothing to do with whether your target can run the code; you need to
> investigate the actual errors seen.
>
>    
This is fairly typical.

FAIL: gcc.target/arm/neon/vzips8.c (test for excess errors)
Excess errors:
vzips8.s:13: Error: selected processor does not support `fldd d17,[fp,#-40]'
vzips8.s:14: Error: selected processor does not support `fldd d16,[fp,#-48]'
vzips8.s:15: Error: selected processor does not support `fstd d17,[fp,#-8]'
vzips8.s:16: Error: selected processor does not support `fstd d16,[fp,#-16]'
vzips8.s:18: Error: selected processor does not support `fldd d16,[fp,#-8]'
vzips8.s:19: Error: selected processor does not support `fldd d17,[fp,#-16]'
vzips8.s:20: Error: selected processor does not support `vmov d18,d16'
vzips8.s:21: Error: selected processor does not support `vmov d19,d17'
vzips8.s:22: Error: bad instruction `vzip.8 d18,d19'
vzips8.s:23: Error: selected processor does not support `vmov d16,d19'
vzips8.s:24: Error: selected processor does not support `vmov d17,d18'
vzips8.s:25: Error: selected processor does not support `fstd d17,[r3,#0]'
vzips8.s:26: Error: selected processor does not support `fstd d16,[r3,#8]'

Would it be better for the arm_neon_ok check to actually put
in an asm for a NEON instruction so it will fail compilation?
I recall us having to do that in a similar situation on another
architecture.

The root is that we have CPU model CFLAGS which apparently
conflict with neon for this board.  So it would be better to make
it fail in arm_neon_ok on a compilation error.

> It looks like arm-rtems may not be an EABI target.  NEON has probably not
> been tested much if at all for non-EABI targets.
>
>    
I am getting the not so subtle feeling that we need to move
to arm-eabi. :)
> Vectorization tests will already test whether NEON code can be executed on
> the target before trying to execute it.  The arm_neon_hw effective-target
> serves that purpose for tests that genuinely need to execute NEON code.
>
>    
OK.


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985

Re: ARM Neon Tests Failing on non-Neon Target

[Joseph S. Myers]

On Fri, 30 Apr 2010, Joel Sherrill wrote:

> This is fairly typical.
> 
> FAIL: gcc.target/arm/neon/vzips8.c (test for excess errors)
> Excess errors:
> vzips8.s:13: Error: selected processor does not support `fldd d17,[fp,#-40]'
[...]
> 
> Would it be better for the arm_neon_ok check to actually put
> in an asm for a NEON instruction so it will fail compilation?
> I recall us having to do that in a similar situation on another
> architecture.
> 
> The root is that we have CPU model CFLAGS which apparently
> conflict with neon for this board.  So it would be better to make
> it fail in arm_neon_ok on a compilation error.

The above errors show that the compiler supports NEON with the given 
options - they do not conflict with NEON - but that the assembler is out 
of sync with the compiler.  That is, the testcase failures indicate a 
compiler bug for your target, rather than a testsuite bug: the compiler 
should be telling the assembler to enable NEON.  For EABI, this is done 
with .cpu, .arch and .fpu directives; for non-EABI you may need to write 
specs to pass command-line options to the assembler.  Creating an 
arm-rtemseabi or similar target and obsoleting the old-ABI version is what 
I'd suggest.  (Having the target not named *eabi* will make various 
testcases not run for it; it's unfortunate enough that EABI testcases need 
to match both arm*-*-*eabi* and arm*-*-symbianelf which is an existing 
EABI target not matching *eabi*.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: ARM Neon Tests Failing on non-Neon Target

[Joel Sherrill]

On 04/30/2010 09:37 AM, Joseph S. Myers wrote:
> On Fri, 30 Apr 2010, Joel Sherrill wrote:
>
>    
>> This is fairly typical.
>>
>> FAIL: gcc.target/arm/neon/vzips8.c (test for excess errors)
>> Excess errors:
>> vzips8.s:13: Error: selected processor does not support `fldd d17,[fp,#-40]'
>>      
> [...]
>    
>> Would it be better for the arm_neon_ok check to actually put
>> in an asm for a NEON instruction so it will fail compilation?
>> I recall us having to do that in a similar situation on another
>> architecture.
>>
>> The root is that we have CPU model CFLAGS which apparently
>> conflict with neon for this board.  So it would be better to make
>> it fail in arm_neon_ok on a compilation error.
>>      
> The above errors show that the compiler supports NEON with the given
> options - they do not conflict with NEON - but that the assembler is out
> of sync with the compiler.  That is, the testcase failures indicate a
> compiler bug for your target, rather than a testsuite bug: the compiler
> should be telling the assembler to enable NEON.
OK.  Sounds like another reason to move RTEMS to be based
upon arm-eabi not arm-elf. :)

I think effort would be better spent doing that.


>   For EABI, this is done
> with .cpu, .arch and .fpu directives; for non-EABI you may need to write
> specs to pass command-line options to the assembler.  Creating an
> arm-rtemseabi or similar target and obsoleting the old-ABI version is what
> I'd suggest.  (Having the target not named *eabi* will make various
> testcases not run for it; it's unfortunate enough that EABI testcases need
> to match both arm*-*-*eabi* and arm*-*-symbianelf which is an existing
> EABI target not matching *eabi*.)
>
>    

Is there any reason to stick with arm-elf as the basis for
arm-rtems?  It looks like arm-eabi is more generally used
and thus more tested and better supported.

-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985

Re: ARM Neon Tests Failing on non-Neon Target

[Joseph S. Myers]

On Fri, 30 Apr 2010, Joel Sherrill wrote:

> >   For EABI, this is done
> > with .cpu, .arch and .fpu directives; for non-EABI you may need to write
> > specs to pass command-line options to the assembler.  Creating an
> > arm-rtemseabi or similar target and obsoleting the old-ABI version is what
> > I'd suggest.  (Having the target not named *eabi* will make various
> > testcases not run for it; it's unfortunate enough that EABI testcases need
> > to match both arm*-*-*eabi* and arm*-*-symbianelf which is an existing
> > EABI target not matching *eabi*.)
> 
> Is there any reason to stick with arm-elf as the basis for
> arm-rtems?  It looks like arm-eabi is more generally used
> and thus more tested and better supported.

My advice is that arm-rtems become a deprecated target like arm-elf and 
arm-linux, and that arm-rtemseabi be the new EABI-based target.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: ARM Neon Tests Failing on non-Neon Target

[Richard Earnshaw]

On Fri, 2010-04-30 at 15:26 +0000, Joseph S. Myers wrote:
> On Fri, 30 Apr 2010, Joel Sherrill wrote:
> 
> > >   For EABI, this is done
> > > with .cpu, .arch and .fpu directives; for non-EABI you may need to write
> > > specs to pass command-line options to the assembler.  Creating an
> > > arm-rtemseabi or similar target and obsoleting the old-ABI version is what
> > > I'd suggest.  (Having the target not named *eabi* will make various
> > > testcases not run for it; it's unfortunate enough that EABI testcases need
> > > to match both arm*-*-*eabi* and arm*-*-symbianelf which is an existing
> > > EABI target not matching *eabi*.)
> > 
> > Is there any reason to stick with arm-elf as the basis for
> > arm-rtems?  It looks like arm-eabi is more generally used
> > and thus more tested and better supported.
> 
> My advice is that arm-rtems become a deprecated target like arm-elf and 
> arm-linux, and that arm-rtemseabi be the new EABI-based target.

Speaking of which, we should probably formally deprecate the old arm-elf
derived targets in 4.6 so that we can remove them in 4.7.

Similarly, we should deprecate support for the FPA on ARM.

R.

Re: ARM Neon Tests Failing on non-Neon Target

[Mark Mitchell]

Richard Earnshaw wrote:

> Speaking of which, we should probably formally deprecate the old arm-elf
> derived targets in 4.6 so that we can remove them in 4.7.

> Similarly, we should deprecate support for the FPA on ARM.

I agree.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713