[Bug target/61153] New: [ARM] vbic vorn tests fail

[Bug target/61153] New: [ARM] vbic vorn tests fail

[christophe.lyon at st dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153

            Bug ID: 61153
           Summary: [ARM] vbic vorn tests fail
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: christophe.lyon at st dot com

Since commit 210216 "Neon intrinsics TLC - Replace intrinsics with GNU C
implementations", I have noticed regressions in the following tests:
  gcc.target/arm/neon/vbicQs16.c scan-assembler vbic[ \t]+[qQ][0-9]+,
[qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
  gcc.target/arm/neon/vbicQs32.c scan-assembler vbic[ \t]+[qQ][0-9]+,
[qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
  gcc.target/arm/neon/vbicQs64.c scan-assembler vbic[ \t]+[qQ][0-9]+,
[qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
  gcc.target/arm/neon/vbicQs8.c scan-assembler vbic[ \t]+[qQ][0-9]+,
[qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
  gcc.target/arm/neon/vbicQu16.c scan-assembler vbic[ \t]+[qQ][0-9]+,
[qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
  gcc.target/arm/neon/vbicQu32.c scan-assembler vbic[ \t]+[qQ][0-9]+,
[qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
  gcc.target/arm/neon/vbicQu64.c scan-assembler vbic[ \t]+[qQ][0-9]+,
[qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
  gcc.target/arm/neon/vbicQu8.c scan-assembler vbic[ \t]+[qQ][0-9]+,
[qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
  gcc.target/arm/neon/vbics16.c scan-assembler vbic[ \t]+[dD][0-9]+,
[dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
  gcc.target/arm/neon/vbics32.c scan-assembler vbic[ \t]+[dD][0-9]+,
[dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
  gcc.target/arm/neon/vbics8.c scan-assembler vbic[ \t]+[dD][0-9]+, [dD][0-9]+,
[dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
  gcc.target/arm/neon/vbicu16.c scan-assembler vbic[ \t]+[dD][0-9]+,
[dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
  gcc.target/arm/neon/vbicu32.c scan-assembler vbic[ \t]+[dD][0-9]+,
[dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
  gcc.target/arm/neon/vbicu8.c scan-assembler vbic[ \t]+[dD][0-9]+, [dD][0-9]+,
[dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
  gcc.target/arm/neon/vornQs16.c scan-assembler vorn[ \t]+[qQ][0-9]+,
[qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
  gcc.target/arm/neon/vornQs32.c scan-assembler vorn[ \t]+[qQ][0-9]+,
[qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
  gcc.target/arm/neon/vornQs64.c scan-assembler vorn[ \t]+[qQ][0-9]+,
[qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
  gcc.target/arm/neon/vornQs8.c scan-assembler vorn[ \t]+[qQ][0-9]+,
[qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
  gcc.target/arm/neon/vornQu16.c scan-assembler vorn[ \t]+[qQ][0-9]+,
[qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
  gcc.target/arm/neon/vornQu32.c scan-assembler vorn[ \t]+[qQ][0-9]+,
[qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
  gcc.target/arm/neon/vornQu64.c scan-assembler vorn[ \t]+[qQ][0-9]+,
[qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
  gcc.target/arm/neon/vornQu8.c scan-assembler vorn[ \t]+[qQ][0-9]+,
[qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
  gcc.target/arm/neon/vorns16.c scan-assembler vorn[ \t]+[dD][0-9]+,
[dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
  gcc.target/arm/neon/vorns32.c scan-assembler vorn[ \t]+[dD][0-9]+,
[dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
  gcc.target/arm/neon/vorns8.c scan-assembler vorn[ \t]+[dD][0-9]+, [dD][0-9]+,
[dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
  gcc.target/arm/neon/vornu16.c scan-assembler vorn[ \t]+[dD][0-9]+,
[dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
  gcc.target/arm/neon/vornu32.c scan-assembler vorn[ \t]+[dD][0-9]+,
[dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
  gcc.target/arm/neon/vornu8.c scan-assembler vorn[ \t]+[dD][0-9]+, [dD][0-9]+,
[dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n

with many --with-target/--with-cpu/--with-fpu configurations as can be seen on
http://cbuild.validation.linaro.org/build/cross-validation/gcc/210216/report-build-info.html

[Bug target/61153] [ARM] vbic vorn tests fail

[ktkachov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153

ktkachov at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ktkachov at gcc dot gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
These are caused by r210216 when those intrinsics were reimplemented in C
rather than using builtins. The only reason they fail is because the tests are
compiled with -O0 which prevents combine from matching the corresponding
patterns.
If compiled with optimisation the tests all work.
I believe the plan is to remove these tests sometime soon anyway.

See http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01836.html for more.

[Bug target/61153] [ARM] vbic vorn tests fail

[christophe.lyon at st dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153

--- Comment #2 from christophe.lyon at st dot com ---
OK, but my tests currently don't inspect the generated code.

They are execution tests, which means the could be PASS using only core
instructions, and no Neon one.

So maybe we should add some optimization level to the existing tests in the
meantime?

[Bug target/61153] [ARM] vbic vorn tests fail

[ktkachov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153

--- Comment #3 from ktkachov at gcc dot gnu.org ---
> So maybe we should add some optimization level to the existing tests in the
> meantime?

Transforming them into something like

#include "arm_neon.h"

volatile int16x8_t arg0_int16x8_t;
volatile int16x8_t arg1_int16x8_t;

int16x8_t test_vbicQs16 (void)
{
  int16x8_t out_int16x8_t;

  return vbicq_s16 (arg0_int16x8_t, arg1_int16x8_t);
}

seems to work at -O2 (i.e. generates vbic and doesn't optimise away the whole
test), so it could be a way to go if the maintainers want it.

To be a bit pedantic, the ACLE spec doesn't strictly require the intrinsics
that the particular NEON instruction is generated, just that the functionality
is as defined in the spec (although the NEON instruction is likely to be the
optimal implementation of that functionality).

Do we plan to keep these scan-assembler tests? or go with just functional
tests?

[Bug target/61153] [ARM] vbic vorn tests fail

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ramana at gcc dot gnu.org

--- Comment #4 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
> Since commit 210216 "Neon intrinsics TLC - Replace intrinsics with GNU C
> implementations", I have noticed regressions in the following tests:
>   gcc.target/arm/neon/vbicQs16.c scan-assembler vbic[ \t]+[qQ][0-9]+,
> [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
>   gcc.target/arm/neon/vbicQs32.c scan-assembler vbic[ \t]+[qQ][0-9]+,
> [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
>   gcc.target/arm/neon/vbicQs64.c scan-assembler vbic[ \t]+[qQ][0-9]+,
> [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
>   gcc.target/arm/neon/vbicQs8.c scan-assembler vbic[ \t]+[qQ][0-9]+,
> [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
>   gcc.target/arm/neon/vbicQu16.c scan-assembler vbic[ \t]+[qQ][0-9]+,
> [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
>   gcc.target/arm/neon/vbicQu32.c scan-assembler vbic[ \t]+[qQ][0-9]+,
> [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
>   gcc.target/arm/neon/vbicQu64.c scan-assembler vbic[ \t]+[qQ][0-9]+,
> [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
>   gcc.target/arm/neon/vbicQu8.c scan-assembler vbic[ \t]+[qQ][0-9]+,
> [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
>   gcc.target/arm/neon/vbics16.c scan-assembler vbic[ \t]+[dD][0-9]+,
> [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
>   gcc.target/arm/neon/vbics32.c scan-assembler vbic[ \t]+[dD][0-9]+,
> [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
>   gcc.target/arm/neon/vbics8.c scan-assembler vbic[ \t]+[dD][0-9]+,
> [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
>   gcc.target/arm/neon/vbicu16.c scan-assembler vbic[ \t]+[dD][0-9]+,
> [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
>   gcc.target/arm/neon/vbicu32.c scan-assembler vbic[ \t]+[dD][0-9]+,
> [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
>   gcc.target/arm/neon/vbicu8.c scan-assembler vbic[ \t]+[dD][0-9]+,
> [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
>   gcc.target/arm/neon/vornQs16.c scan-assembler vorn[ \t]+[qQ][0-9]+,
> [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
>   gcc.target/arm/neon/vornQs32.c scan-assembler vorn[ \t]+[qQ][0-9]+,
> [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
>   gcc.target/arm/neon/vornQs64.c scan-assembler vorn[ \t]+[qQ][0-9]+,
> [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
>   gcc.target/arm/neon/vornQs8.c scan-assembler vorn[ \t]+[qQ][0-9]+,
> [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
>   gcc.target/arm/neon/vornQu16.c scan-assembler vorn[ \t]+[qQ][0-9]+,
> [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
>   gcc.target/arm/neon/vornQu32.c scan-assembler vorn[ \t]+[qQ][0-9]+,
> [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
>   gcc.target/arm/neon/vornQu64.c scan-assembler vorn[ \t]+[qQ][0-9]+,
> [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
>   gcc.target/arm/neon/vornQu8.c scan-assembler vorn[ \t]+[qQ][0-9]+,
> [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
>   gcc.target/arm/neon/vorns16.c scan-assembler vorn[ \t]+[dD][0-9]+,
> [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
>   gcc.target/arm/neon/vorns32.c scan-assembler vorn[ \t]+[dD][0-9]+,
> [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
>   gcc.target/arm/neon/vorns8.c scan-assembler vorn[ \t]+[dD][0-9]+,
> [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
>   gcc.target/arm/neon/vornu16.c scan-assembler vorn[ \t]+[dD][0-9]+,
> [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
>   gcc.target/arm/neon/vornu32.c scan-assembler vorn[ \t]+[dD][0-9]+,
> [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n
>   gcc.target/arm/neon/vornu8.c scan-assembler vorn[ \t]+[dD][0-9]+,
> [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n


Yes that is expected as per my original patch submission. Patch 1/3 said these
tests would fail because at O0 combine doesn't run.

I'm expecting your run time tests to go in and for cases where we need them, we
may want to put out some kind of basic scan assembler tests for them.

I'm tempted to mark this as invalid.


> 
> with many --with-target/--with-cpu/--with-fpu configurations as can be seen
> on
> http://cbuild.validation.linaro.org/build/cross-validation/gcc/210216/report-
> build-info.html

[Bug target/61153] [ARM] vbic vorn tests fail

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153

--- Comment #5 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---

> Do we plan to keep these scan-assembler tests? or go with just functional
> tests?

No, not these scan assembler tests. They serve no purpose. 

I'm expecting them to get replaced by the testsuite you've been writing up and
would like them to include any kind of scan-assembler tests if possible.

Ramana

[Bug target/61153] [ARM] vbic vorn tests fail

[christophe.lyon at st dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153

--- Comment #6 from christophe.lyon at st dot com ---
(In reply to Ramana Radhakrishnan from comment #4)
> Yes that is expected as per my original patch submission. Patch 1/3 said
> these tests would fail because at O0 combine doesn't run.

Indeed, sorry I forgot about it.

> I'm expecting your run time tests to go in and for cases where we need them,
> we may want to put out some kind of basic scan assembler tests for them.
> 
> I'm tempted to mark this as invalid.
> 

How do we define "cases where we need them"? My concern is that some compiler
change might cause a suboptimal-yet-functional code to be generated, and we
wouldn't notice it.

[Bug target/61153] [ARM] vbic vorn tests fail

[christophe.lyon at st dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153

--- Comment #7 from christophe.lyon at st dot com ---
(In reply to Ramana Radhakrishnan from comment #5)
> > Do we plan to keep these scan-assembler tests? or go with just functional
> > tests?
> 
> No, not these scan assembler tests. They serve no purpose. 
> 
> I'm expecting them to get replaced by the testsuite you've been writing up
> and would like them to include any kind of scan-assembler tests if possible.
> 

Good suggestion, I'll look at how easily I can add that.

[Bug target/61153] [ARM] vbic vorn tests fail

[ramana.radhakrishnan at arm dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153

--- Comment #8 from ramana.radhakrishnan at arm dot com <ramana.radhakrishnan at arm dot com> ---
>
> How do we define "cases where we need them"? My concern is that some compiler
> change might cause a suboptimal-yet-functional code to be generated, and we
> wouldn't notice it.
>

Well, currently tests in gcc.target/arm/neon serve no functional / 
correctness purpose. The only thing they check is if the correct 
instruction is generated at O0 which is probably enough for that case.

I would rather that we put in scan-assembler tests in your testsuite 
rather than anything else.

regards
Ramana

[Bug target/61153] [ARM] vbic vorn tests fail

[bernd.edlinger at hotmail dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153

Bernd Edlinger <bernd.edlinger at hotmail dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bernd.edlinger at hotmail dot de

--- Comment #9 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Hi, these tests are still failing.
what are we gonna do about it?

[Bug target/61153] [ARM] vbic vorn tests fail

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153

--- Comment #10 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to Bernd Edlinger from comment #9)
> Hi, these tests are still failing.
> what are we gonna do about it?


I am happy for a patch to delete them.


Ramana

[Bug target/61153] [ARM] vbic vorn tests fail

[christophe.lyon at st dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153

--- Comment #11 from christophe.lyon at st dot com ---
(In reply to Ramana Radhakrishnan from comment #10)
> (In reply to Bernd Edlinger from comment #9)
> > Hi, these tests are still failing.
> > what are we gonna do about it?
>  
> 
> I am happy for a patch to delete them.
> 
> 
> Ramana

What about modifying the tests to use -O2 instead of -O0?

At least, this would enable checking that the expected instruction is
generated.

[Bug target/61153] [ARM] vbic vorn tests fail

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153

--- Comment #12 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to christophe.lyon from comment #11)
> (In reply to Ramana Radhakrishnan from comment #10)
> > (In reply to Bernd Edlinger from comment #9)
> > > Hi, these tests are still failing.
> > > what are we gonna do about it?
> >  
> > 
> > I am happy for a patch to delete them.
> > 
> > 
> > Ramana
> 
> What about modifying the tests to use -O2 instead of -O0?
> 
> At least, this would enable checking that the expected instruction is
> generated.

Sure - patches welcome :)

[Bug target/61153] [ARM] vbic vorn tests fail

[christophe.lyon at st dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153

christophe.lyon at st dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #13 from christophe.lyon at st dot com ---
Fixed by r217707