Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[Tim Northover via cfe-commits]

On 1 December 2015 at 10:42, James Molloy via cfe-commits
 wrote:
> W.r.t the test-suite, that is a possibility. There are currently no
> codegen-filecheck tests in the test-suite but there seems to be no reason I
> can see why not. The disadvantage there for me is that we take short
> running, simple tests and demote them to be run less often.

Compared to test-suite these are short-running. But compared to
virtually everything else in check-all they're beasts.

I've been meaning to do *something* about them for a long while.
They're not even particularly good: these days they're a huge
hand-written mess and they don't test data flow at all.

Given how the code is actually generated, it would be absurdly easy to
accidentally feed LHS into an LLVM instruction twice by mistake. For a
long while we randomly flipped the operand order in vfma_lane_* on
Darwin, and had to phase that out gradually.

Unfortunately, I haven't actually come up with a better replacement.
Even if we could magically replace each one with a test of LLVM IR I
don't think it would improve things massively.

Tim.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[Eric Christopher via cfe-commits]

Hi James,

I disagree with you completely on every point except that you need to write
new tests.

There is absolutely, as I said in the thread where I noticed this for the
x86 intrinsics, that you cannot supply this test up and test it in the
front and the back end separately. If you believe this is impossible please
let me know why, but clang and llvm are designed to be tested as I stated.
As far as prior art, I can only apologize that I didn't see them before,
I'm sure you know how hard it is to review everything.

Thanks

-eric

On Tue, Dec 1, 2015, 3:44 AM James Molloy  wrote:

Hi Eric,

While I agree with you in principle, Alexandros has just pointed out to me
that all the other NEON intrinsics have such -O3 tests, and thinking about
it I do think they add value. They test the full-trip through the compiler
and ensure that Clang and LLVM have matching ideas of the IR interface
exposed by the intrinsics.

AIUI, Alexandros wrote LLVM backend tests in addition to these. It does
look like there are no tests just checking Clang's IR output - I think
these should indeed be written.

In summary, I agree with you that we need tests for both Clang and LLVM
separately. However I also think the full-trip tests add significant value
and wouldn't like to see them removed, and there's significant prior art in
this area so if we did decide they needed to be gone, we'd need a good
discussion on how to regain the testing coverage we'd lose.



Cheers,

James

On Sun, 29 Nov 2015 at 20:40 Eric Christopher via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

Hi,

This is entirely the wrong way to do these tests. They shouldn't depend on
assembly output or optimization. Please split them onto frontend IR tests
and backend assembly tests.

Thanks!

On Sun, Nov 29, 2015, 2:56 AM Alexandros Lamprineas via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

Author: alelab01
Date: Sun Nov 29 04:53:28 2015
New Revision: 254251

URL: http:// 
llvm.org /
viewvc
/
llvm-project

?rev=254251=rev

Log:
ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply
Add/Subtract.

Add missing tests that accidentally were not committed in rL254250.

Differential Revision: http:// 
reviews.llvm.org /D14982


Added:
cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c
cfe/trunk/test/CodeGen/arm-v8.1a-neon-intrinsics.c

Added: cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c
URL: http://

llvm.org

/

viewvc

/

llvm-project

/

cfe

/trunk/test/

CodeGen

/

aarch64-v8.1a-neon-intrinsics.c

?rev=254251=auto

==
--- cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c (added)
+++ cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c Sun Nov 29
04:53:28 2015
@@ -0,0 +1,128 @@
+// REQUIRES: aarch64-registered-target
+
+// RUN: %clang_cc1 -triple aarch64-linux-gnu -target-feature +neon \
+// RUN:  -target-feature +v8.1a -O3 -S -o - %s \
+// RUN:  | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-AARCH64
+
+ #include 
+
+// CHECK-AARCH64-LABEL: test_vqrdmlah_laneq_s16
+int16x4_t 

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[James Molloy via cfe-commits]

Hi Eric,

This isn't just a NEON intrinsics thing, and this isn't just an ARM/AArch64
thing. There needs to be some way to test the compiler from start to
finish. Not being able to do so leaves serious coverage holes.

Unit testing is great, but integration testing is required sometimes to
ensure multiple units interface as expected. I could grab a bunch of
examples from the clang tests directory that my grep has just thrown up -
CodeGen/nobuiltin.c, for example, or
CodeGen/aarch64-fix-cortex-a53-835769.c, where we absolutely 100% must
ensure that the -mfix-cortex-a53-835769 flag gets properly respected in the
compiler output.

If you can describe a way to get the same strength of testing without
running the backend during clang tests, I'm all ears!

James

On Tue, 1 Dec 2015 at 16:59 Eric Christopher  wrote:

> Hi James,
>
> I disagree with you completely on every point except that you need to
> write new tests.
>
> There is absolutely, as I said in the thread where I noticed this for the
> x86 intrinsics, that you cannot supply this test up and test it in the
> front and the back end separately. If you believe this is impossible please
> let me know why, but clang and llvm are designed to be tested as I stated.
> As far as prior art, I can only apologize that I didn't see them before,
> I'm sure you know how hard it is to review everything.
>
> Thanks
>
> -eric
>
> On Tue, Dec 1, 2015, 3:44 AM James Molloy  wrote:
>
> Hi Eric,
>
> While I agree with you in principle, Alexandros has just pointed out to me
> that all the other NEON intrinsics have such -O3 tests, and thinking about
> it I do think they add value. They test the full-trip through the compiler
> and ensure that Clang and LLVM have matching ideas of the IR interface
> exposed by the intrinsics.
>
> AIUI, Alexandros wrote LLVM backend tests in addition to these. It does
> look like there are no tests just checking Clang's IR output - I think
> these should indeed be written.
>
> In summary, I agree with you that we need tests for both Clang and LLVM
> separately. However I also think the full-trip tests add significant value
> and wouldn't like to see them removed, and there's significant prior art in
> this area so if we did decide they needed to be gone, we'd need a good
> discussion on how to regain the testing coverage we'd lose.
>
>
>
> Cheers,
>
> James
>
> On Sun, 29 Nov 2015 at 20:40 Eric Christopher via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> Hi,
>
> This is entirely the wrong way to do these tests. They shouldn't depend on
> assembly output or optimization. Please split them onto frontend IR tests
> and backend assembly tests.
>
> Thanks!
>
> On Sun, Nov 29, 2015, 2:56 AM Alexandros Lamprineas via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> Author: alelab01
> Date: Sun Nov 29 04:53:28 2015
> New Revision: 254251
>
> URL: http:// 
> llvm.org /
> viewvc
> /
> llvm-project
> 
> ?rev=254251=rev
> 
> Log:
> ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply
> Add/Subtract.
>
> Add missing tests that accidentally were not committed in rL254250.
>
> Differential Revision: http:// 
> reviews.llvm.org /D14982
> 
>
> Added:
> cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c
> cfe/trunk/test/CodeGen/arm-v8.1a-neon-intrinsics.c
>
> Added: cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c
> URL: http://
> 
> llvm.org
> 
> /
> 
> viewvc
> 
> /
> 
> llvm-project
> 
> /
> 
> cfe
> 
> /trunk/test/
> 
> CodeGen
> 

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[David Blaikie via cfe-commits]

On Tue, Dec 1, 2015 at 9:56 AM, Renato Golin via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On 1 December 2015 at 17:23, James Molloy via cfe-commits
>  wrote:
> > This isn't just a NEON intrinsics thing, and this isn't just an
> ARM/AArch64
> > thing. There needs to be some way to test the compiler from start to
> finish.
> > Not being able to do so leaves serious coverage holes.
>
> Just for the sake of completeness, a hole that the test-suite doesn't
> cover.
>

Are they things the test-suite couldn't (either technically or
philosophically) cover, or only that it doesn't cover it at the moment, but
could do so?


>
>
> > CodeGen/aarch64-fix-cortex-a53-835769.c, where we absolutely 100% must
> > ensure that the -mfix-cortex-a53-835769 flag gets properly respected in
> the
> > compiler output.
>
> SIMD intrinsics (including NEON, SSE), Errata fixes, Procedure call
> tests, ELF section placement, FP contracts, Debug info, Inline
> assembly, Unicode support, object creation, library symbol clashes,
> back-end diagnostics are some of the examples that need to go all the
> way to asm or object code.
>
>
> > If you can describe a way to get the same strength of testing without
> > running the backend during clang tests, I'm all ears!
>
> I'm particularly interested in how do we keep the IR printed in the
> Clang tests in sync with the IR sent to the LLVM tests if/when they
> change, to guarantee that Clang changes don't generate silent codegen
> faults down the line in LLVM and vice-versa.
>

That would sort of defeat the point of having the testing and projects
separated though - it would tie the tests together and produce most of the
undesirable outcomes of having single end-to-end tests.

(it would mean that at least the pure (or at least non-Clang) LLVM
developer would have a test to run where they would not if the test
remained in Clang only)


>
> cheers,
> --renato
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[Renato Golin via cfe-commits]

On 1 December 2015 at 17:23, James Molloy via cfe-commits
 wrote:
> This isn't just a NEON intrinsics thing, and this isn't just an ARM/AArch64
> thing. There needs to be some way to test the compiler from start to finish.
> Not being able to do so leaves serious coverage holes.

Just for the sake of completeness, a hole that the test-suite doesn't cover.


> CodeGen/aarch64-fix-cortex-a53-835769.c, where we absolutely 100% must
> ensure that the -mfix-cortex-a53-835769 flag gets properly respected in the
> compiler output.

SIMD intrinsics (including NEON, SSE), Errata fixes, Procedure call
tests, ELF section placement, FP contracts, Debug info, Inline
assembly, Unicode support, object creation, library symbol clashes,
back-end diagnostics are some of the examples that need to go all the
way to asm or object code.


> If you can describe a way to get the same strength of testing without
> running the backend during clang tests, I'm all ears!

I'm particularly interested in how do we keep the IR printed in the
Clang tests in sync with the IR sent to the LLVM tests if/when they
change, to guarantee that Clang changes don't generate silent codegen
faults down the line in LLVM and vice-versa.

cheers,
--renato
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[Eric Christopher via cfe-commits]

On Tue, Dec 1, 2015 at 9:23 AM James Molloy  wrote:

> Hi Eric,
>
> This isn't just a NEON intrinsics thing, and this isn't just an
> ARM/AArch64 thing. There needs to be some way to test the compiler from
> start to finish. Not being able to do so leaves serious coverage holes.
>
> Unit testing is great, but integration testing is required sometimes to
> ensure multiple units interface as expected. I could grab a bunch of
> examples from the clang tests directory that my grep has just thrown up -
> CodeGen/nobuiltin.c, for example, or
> CodeGen/aarch64-fix-cortex-a53-835769.c, where we absolutely 100% must
> ensure that the -mfix-cortex-a53-835769 flag gets properly respected in the
> compiler output.
>
>
The code gen one is easy. "Did the subtarget feature get passed to the
backend"?

Then in the backend make sure that the pass ran by either checking the
output or checking the debug output. Simple.

I haven't looked at the other one at the moment.

-eric


> If you can describe a way to get the same strength of testing without
> running the backend during clang tests, I'm all ears!
>
> James
>
> On Tue, 1 Dec 2015 at 16:59 Eric Christopher  wrote:
>
>> Hi James,
>>
>> I disagree with you completely on every point except that you need to
>> write new tests.
>>
>> There is absolutely, as I said in the thread where I noticed this for the
>> x86 intrinsics, that you cannot supply this test up and test it in the
>> front and the back end separately. If you believe this is impossible please
>> let me know why, but clang and llvm are designed to be tested as I stated.
>> As far as prior art, I can only apologize that I didn't see them before,
>> I'm sure you know how hard it is to review everything.
>>
>> Thanks
>>
>> -eric
>>
>> On Tue, Dec 1, 2015, 3:44 AM James Molloy 
>> wrote:
>>
>> Hi Eric,
>>
>> While I agree with you in principle, Alexandros has just pointed out to
>> me that all the other NEON intrinsics have such -O3 tests, and thinking
>> about it I do think they add value. They test the full-trip through the
>> compiler and ensure that Clang and LLVM have matching ideas of the IR
>> interface exposed by the intrinsics.
>>
>> AIUI, Alexandros wrote LLVM backend tests in addition to these. It does
>> look like there are no tests just checking Clang's IR output - I think
>> these should indeed be written.
>>
>> In summary, I agree with you that we need tests for both Clang and LLVM
>> separately. However I also think the full-trip tests add significant value
>> and wouldn't like to see them removed, and there's significant prior art in
>> this area so if we did decide they needed to be gone, we'd need a good
>> discussion on how to regain the testing coverage we'd lose.
>>
>>
>>
>> Cheers,
>>
>> James
>>
>> On Sun, 29 Nov 2015 at 20:40 Eric Christopher via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>> Hi,
>>
>> This is entirely the wrong way to do these tests. They shouldn't depend
>> on assembly output or optimization. Please split them onto frontend IR
>> tests and backend assembly tests.
>>
>> Thanks!
>>
>> On Sun, Nov 29, 2015, 2:56 AM Alexandros Lamprineas via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>> Author: alelab01
>> Date: Sun Nov 29 04:53:28 2015
>> New Revision: 254251
>>
>> URL: http:// 
>> llvm.org /
>> viewvc
>> /
>> llvm-project
>> 
>> ?rev=254251=rev
>> 
>> Log:
>> ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply
>> Add/Subtract.
>>
>> Add missing tests that accidentally were not committed in rL254250.
>>
>> Differential Revision: http:// 
>> reviews.llvm.org /D14982
>> 
>>
>> Added:
>> cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c
>> cfe/trunk/test/CodeGen/arm-v8.1a-neon-intrinsics.c
>>
>> Added: cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c
>> URL: http://
>> 
>> llvm.org
>> 
>> /
>> 
>> viewvc
>> 
>> /
>> 
>> llvm-project
>> 

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[Renato Golin via cfe-commits]

On 1 December 2015 at 18:29, David Blaikie  wrote:
> Are they things the test-suite couldn't (either technically or
> philosophically) cover, or only that it doesn't cover it at the moment, but
> could do so?

IMO, it's a philosophical issue. The test-suite is a whole-program
execution, and all that matters is the end result, the output of the
program, not the program itself.

Those tests are mostly large (> 3 lines of code) so, if we were trying
to objdump and match for instruction patterns, any optimisation
variance could destroy them, as well as you may find the pattern
elsewhere in the same object, not belonging to the function you want
(inlining, etc). All in all, all the problems with reducing C code
would be pertinent here, so a big hammer to kill small issues. On the
other hand, the Clang based asm/obj examples are all small, and
hand-crafted to suit the problem being tested.

We could, however, add a new directory in the test-suite for that kind
of tests, like we already have for regressions in C/C++. That would
dissociate the front-end from the back-end, and essentially any
compiler used would have to abide by the rules of the test (which may
not be true for some compilers).

I don't mind where they end up, really, but we need that kind of test
somewhere. Clang is an easy place because we know we have it built
when the Clang repo is checked out.


> That would sort of defeat the point of having the testing and projects
> separated though - it would tie the tests together and produce most of the
> undesirable outcomes of having single end-to-end tests.

Right, I agree, but since the relationship between Clang and LLVM is
non-trivial, and there are lots of changes that need to be done on
both sides, I can't see why we shouldn't have tests that span across
projects.

Clearly, the sanitizer tests need Clang and Compiler-RT. Some Libc++
tests need Compiler-RT, others need libunwind, on ARM I need Clang to
build it. There are a lot of dependencies that are not there by
accident, but by design.

The more you move tests away from the big targets (LLVM, Clang), the
less they're ran by people committing patches, and the harder will be
to pick up the failures. Having said that, a decent buildbot coverage
would account for most of those problems, but it would also put a
stress on slow/expensive/experimental hardware support. It's a
balance, I think.


> (it would mean that at least the pure (or at least non-Clang) LLVM developer
> would have a test to run where they would not if the test remained in Clang
> only)

That is a good point. Right now, RT/libc++ tests in that category are
controlled by enabling/disabling support via CMake flags. We may be
able to do the same with Clang (if LLVM is not built with it, disable
asm/obj tests). Moving them all to a regression package in the
test-suite would be another option, but one that would take a lot
longer...

cheers,
--renato
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[James Molloy via cfe-commits]

Hi,

> That would sort of defeat the point of having the testing and projects
separated though - it would tie the tests together and produce most of the
undesirable outcomes of having single end-to-end tests.

End to end tests have significant disadvantages as we all know. However
they do have some advantages too( that I have already enumerated) and the
question currently as I see it is how do we best get/keep those advantages
in our testing strategy?

W.r.t the test-suite, that is a possibility. There are currently no
codegen-filecheck tests in the test-suite but there seems to be no reason I
can see why not. The disadvantage there for me is that we take short
running, simple tests and demote them to be run less often.

Would it make sense to have a dedicated subdirectory in clang/test for
these kind of tests, so they can be directly enumerated and therefore kept
to a minimum , yet be allowed when they add value?

James
On Tue, 1 Dec 2015 at 18:29, David Blaikie  wrote:

> On Tue, Dec 1, 2015 at 9:56 AM, Renato Golin via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On 1 December 2015 at 17:23, James Molloy via cfe-commits
>>  wrote:
>> > This isn't just a NEON intrinsics thing, and this isn't just an
>> ARM/AArch64
>> > thing. There needs to be some way to test the compiler from start to
>> finish.
>> > Not being able to do so leaves serious coverage holes.
>>
>> Just for the sake of completeness, a hole that the test-suite doesn't
>> cover.
>>
>
> Are they things the test-suite couldn't (either technically or
> philosophically) cover, or only that it doesn't cover it at the moment, but
> could do so?
>
>
>>
>>
>> > CodeGen/aarch64-fix-cortex-a53-835769.c, where we absolutely 100% must
>> > ensure that the -mfix-cortex-a53-835769 flag gets properly respected in
>> the
>> > compiler output.
>>
>> SIMD intrinsics (including NEON, SSE), Errata fixes, Procedure call
>> tests, ELF section placement, FP contracts, Debug info, Inline
>> assembly, Unicode support, object creation, library symbol clashes,
>> back-end diagnostics are some of the examples that need to go all the
>> way to asm or object code.
>>
>>
>> > If you can describe a way to get the same strength of testing without
>> > running the backend during clang tests, I'm all ears!
>>
>> I'm particularly interested in how do we keep the IR printed in the
>> Clang tests in sync with the IR sent to the LLVM tests if/when they
>> change, to guarantee that Clang changes don't generate silent codegen
>> faults down the line in LLVM and vice-versa.
>>
>
> That would sort of defeat the point of having the testing and projects
> separated though - it would tie the tests together and produce most of the
> undesirable outcomes of having single end-to-end tests.
>
> (it would mean that at least the pure (or at least non-Clang) LLVM
> developer would have a test to run where they would not if the test
> remained in Clang only)
>
>
>>
>> cheers,
>> --renato
>
>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[Eric Christopher via cfe-commits]

On Tue, Dec 1, 2015 at 10:43 AM James Molloy via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Hi,
>
> > That would sort of defeat the point of having the testing and projects
> separated though - it would tie the tests together and produce most of the
> undesirable outcomes of having single end-to-end tests.
>
> End to end tests have significant disadvantages as we all know. However
> they do have some advantages too( that I have already enumerated) and the
> question currently as I see it is how do we best get/keep those advantages
> in our testing strategy?
>
> W.r.t the test-suite, that is a possibility. There are currently no
> codegen-filecheck tests in the test-suite but there seems to be no reason I
> can see why not. The disadvantage there for me is that we take short
> running, simple tests and demote them to be run less often.
>
> Would it make sense to have a dedicated subdirectory in clang/test for
> these kind of tests, so they can be directly enumerated and therefore kept
> to a minimum , yet be allowed when they add value?
>
>
There are a few cases where we can't currently test something, but none of
the cases you or Renato have brought up qualify. I'm curious what you'd put
in this directory?

-eric


> James
> On Tue, 1 Dec 2015 at 18:29, David Blaikie  wrote:
>
>> On Tue, Dec 1, 2015 at 9:56 AM, Renato Golin via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> On 1 December 2015 at 17:23, James Molloy via cfe-commits
>>>  wrote:
>>> > This isn't just a NEON intrinsics thing, and this isn't just an
>>> ARM/AArch64
>>> > thing. There needs to be some way to test the compiler from start to
>>> finish.
>>> > Not being able to do so leaves serious coverage holes.
>>>
>>> Just for the sake of completeness, a hole that the test-suite doesn't
>>> cover.
>>>
>>
>> Are they things the test-suite couldn't (either technically or
>> philosophically) cover, or only that it doesn't cover it at the moment, but
>> could do so?
>>
>>
>>>
>>>
>>> > CodeGen/aarch64-fix-cortex-a53-835769.c, where we absolutely 100% must
>>> > ensure that the -mfix-cortex-a53-835769 flag gets properly respected
>>> in the
>>> > compiler output.
>>>
>>> SIMD intrinsics (including NEON, SSE), Errata fixes, Procedure call
>>> tests, ELF section placement, FP contracts, Debug info, Inline
>>> assembly, Unicode support, object creation, library symbol clashes,
>>> back-end diagnostics are some of the examples that need to go all the
>>> way to asm or object code.
>>>
>>>
>>> > If you can describe a way to get the same strength of testing without
>>> > running the backend during clang tests, I'm all ears!
>>>
>>> I'm particularly interested in how do we keep the IR printed in the
>>> Clang tests in sync with the IR sent to the LLVM tests if/when they
>>> change, to guarantee that Clang changes don't generate silent codegen
>>> faults down the line in LLVM and vice-versa.
>>>
>>
>> That would sort of defeat the point of having the testing and projects
>> separated though - it would tie the tests together and produce most of the
>> undesirable outcomes of having single end-to-end tests.
>>
>> (it would mean that at least the pure (or at least non-Clang) LLVM
>> developer would have a test to run where they would not if the test
>> remained in Clang only)
>>
>>
>>>
>>> cheers,
>>> --renato
>>
>>
>>> ___
>>> cfe-commits mailing list
>>> cfe-commits@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>
>> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[James Molloy via cfe-commits]

You cannot test the intrinsic emission with the same quality when splitting
the test in two. You miss testing the producer consumer relationship
between the two components.

I'm sorry that this use case appears to you as not qualifying.
On Tue, 1 Dec 2015 at 18:45, Eric Christopher  wrote:

> On Tue, Dec 1, 2015 at 10:43 AM James Molloy via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Hi,
>>
>> > That would sort of defeat the point of having the testing and projects
>> separated though - it would tie the tests together and produce most of the
>> undesirable outcomes of having single end-to-end tests.
>>
>> End to end tests have significant disadvantages as we all know. However
>> they do have some advantages too( that I have already enumerated) and the
>> question currently as I see it is how do we best get/keep those advantages
>> in our testing strategy?
>>
>> W.r.t the test-suite, that is a possibility. There are currently no
>> codegen-filecheck tests in the test-suite but there seems to be no reason I
>> can see why not. The disadvantage there for me is that we take short
>> running, simple tests and demote them to be run less often.
>>
>> Would it make sense to have a dedicated subdirectory in clang/test for
>> these kind of tests, so they can be directly enumerated and therefore kept
>> to a minimum , yet be allowed when they add value?
>>
>>
> There are a few cases where we can't currently test something, but none of
> the cases you or Renato have brought up qualify. I'm curious what you'd put
> in this directory?
>
> -eric
>
>
>> James
>> On Tue, 1 Dec 2015 at 18:29, David Blaikie  wrote:
>>
>>> On Tue, Dec 1, 2015 at 9:56 AM, Renato Golin via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 On 1 December 2015 at 17:23, James Molloy via cfe-commits
  wrote:
 > This isn't just a NEON intrinsics thing, and this isn't just an
 ARM/AArch64
 > thing. There needs to be some way to test the compiler from start to
 finish.
 > Not being able to do so leaves serious coverage holes.

 Just for the sake of completeness, a hole that the test-suite doesn't
 cover.

>>>
>>> Are they things the test-suite couldn't (either technically or
>>> philosophically) cover, or only that it doesn't cover it at the moment, but
>>> could do so?
>>>
>>>


 > CodeGen/aarch64-fix-cortex-a53-835769.c, where we absolutely 100% must
 > ensure that the -mfix-cortex-a53-835769 flag gets properly respected
 in the
 > compiler output.

 SIMD intrinsics (including NEON, SSE), Errata fixes, Procedure call
 tests, ELF section placement, FP contracts, Debug info, Inline
 assembly, Unicode support, object creation, library symbol clashes,
 back-end diagnostics are some of the examples that need to go all the
 way to asm or object code.


 > If you can describe a way to get the same strength of testing without
 > running the backend during clang tests, I'm all ears!

 I'm particularly interested in how do we keep the IR printed in the
 Clang tests in sync with the IR sent to the LLVM tests if/when they
 change, to guarantee that Clang changes don't generate silent codegen
 faults down the line in LLVM and vice-versa.

>>>
>>> That would sort of defeat the point of having the testing and projects
>>> separated though - it would tie the tests together and produce most of the
>>> undesirable outcomes of having single end-to-end tests.
>>>
>>> (it would mean that at least the pure (or at least non-Clang) LLVM
>>> developer would have a test to run where they would not if the test
>>> remained in Clang only)
>>>
>>>

 cheers,
 --renato
>>>
>>>
 ___
 cfe-commits mailing list
 cfe-commits@lists.llvm.org
 http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

>>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[Eric Christopher via cfe-commits]

Could you provide an example proving this? I answered your question with
exactly how to split it up.

On Tue, Dec 1, 2015, 10:54 AM James Molloy  wrote:

> You cannot test the intrinsic emission with the same quality when
> splitting the test in two. You miss testing the producer consumer
> relationship between the two components.
>
> I'm sorry that this use case appears to you as not qualifying.
> On Tue, 1 Dec 2015 at 18:45, Eric Christopher  wrote:
>
>> On Tue, Dec 1, 2015 at 10:43 AM James Molloy via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Hi,
>>>
>>> > That would sort of defeat the point of having the testing and projects
>>> separated though - it would tie the tests together and produce most of the
>>> undesirable outcomes of having single end-to-end tests.
>>>
>>> End to end tests have significant disadvantages as we all know. However
>>> they do have some advantages too( that I have already enumerated) and the
>>> question currently as I see it is how do we best get/keep those advantages
>>> in our testing strategy?
>>>
>>> W.r.t the test-suite, that is a possibility. There are currently no
>>> codegen-filecheck tests in the test-suite but there seems to be no reason I
>>> can see why not. The disadvantage there for me is that we take short
>>> running, simple tests and demote them to be run less often.
>>>
>>> Would it make sense to have a dedicated subdirectory in clang/test for
>>> these kind of tests, so they can be directly enumerated and therefore kept
>>> to a minimum , yet be allowed when they add value?
>>>
>>>
>> There are a few cases where we can't currently test something, but none
>> of the cases you or Renato have brought up qualify. I'm curious what you'd
>> put in this directory?
>>
>> -eric
>>
>>
>>> James
>>> On Tue, 1 Dec 2015 at 18:29, David Blaikie  wrote:
>>>
 On Tue, Dec 1, 2015 at 9:56 AM, Renato Golin via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

> On 1 December 2015 at 17:23, James Molloy via cfe-commits
>  wrote:
> > This isn't just a NEON intrinsics thing, and this isn't just an
> ARM/AArch64
> > thing. There needs to be some way to test the compiler from start to
> finish.
> > Not being able to do so leaves serious coverage holes.
>
> Just for the sake of completeness, a hole that the test-suite doesn't
> cover.
>

 Are they things the test-suite couldn't (either technically or
 philosophically) cover, or only that it doesn't cover it at the moment, but
 could do so?


>
>
> > CodeGen/aarch64-fix-cortex-a53-835769.c, where we absolutely 100%
> must
> > ensure that the -mfix-cortex-a53-835769 flag gets properly respected
> in the
> > compiler output.
>
> SIMD intrinsics (including NEON, SSE), Errata fixes, Procedure call
> tests, ELF section placement, FP contracts, Debug info, Inline
> assembly, Unicode support, object creation, library symbol clashes,
> back-end diagnostics are some of the examples that need to go all the
> way to asm or object code.
>
>
> > If you can describe a way to get the same strength of testing without
> > running the backend during clang tests, I'm all ears!
>
> I'm particularly interested in how do we keep the IR printed in the
> Clang tests in sync with the IR sent to the LLVM tests if/when they
> change, to guarantee that Clang changes don't generate silent codegen
> faults down the line in LLVM and vice-versa.
>

 That would sort of defeat the point of having the testing and projects
 separated though - it would tie the tests together and produce most of the
 undesirable outcomes of having single end-to-end tests.

 (it would mean that at least the pure (or at least non-Clang) LLVM
 developer would have a test to run where they would not if the test
 remained in Clang only)


>
> cheers,
> --renato


> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
 ___
>>> cfe-commits mailing list
>>> cfe-commits@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>
>>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[David Blaikie via cfe-commits]

On Tue, Dec 1, 2015 at 10:43 AM, Renato Golin 
wrote:

> On 1 December 2015 at 18:29, David Blaikie  wrote:
> > Are they things the test-suite couldn't (either technically or
> > philosophically) cover, or only that it doesn't cover it at the moment,
> but
> > could do so?
>
> IMO, it's a philosophical issue. The test-suite is a whole-program
> execution, and all that matters is the end result, the output of the
> program, not the program itself.
>
> Those tests are mostly large (> 3 lines of code) so, if we were trying
> to objdump and match for instruction patterns, any optimisation
> variance could destroy them, as well as you may find the pattern
> elsewhere in the same object, not belonging to the function you want
> (inlining, etc).


Not sure I follow - I'm not suggesting adding objdump/instruction checking
to existing large programs in the test-suite, but adding other tests to the
test-suite that do this and have appropriate input for it to be a
reliable/useful form of testing.


> All in all, all the problems with reducing C code
> would be pertinent here, so a big hammer to kill small issues. On the
> other hand, the Clang based asm/obj examples are all small, and
> hand-crafted to suit the problem being tested.
>
> We could, however, add a new directory in the test-suite for that kind
> of tests, like we already have for regressions in C/C++.


If a separate directory makes it more clear what the purpose is, sure,
seems fine to me, but I don't have strong or informed opinions on exactly
how the test-suite is laid out.


> That would
> dissociate the front-end from the back-end, and essentially any
> compiler used would have to abide by the rules of the test (which may
> not be true for some compilers).
>

This is perhaps an interesting part/point: In theory I would think that
these tests should be able to be phrased in a compiler-agnostic way, since
they're testing the compiler as a whole and testing behavior that the
source code demands, no?


> I don't mind where they end up, really, but we need that kind of test
> somewhere. Clang is an easy place because we know we have it built
> when the Clang repo is checked out.
>
>
> > That would sort of defeat the point of having the testing and projects
> > separated though - it would tie the tests together and produce most of
> the
> > undesirable outcomes of having single end-to-end tests.
>
> Right, I agree, but since the relationship between Clang and LLVM is
> non-trivial, and there are lots of changes that need to be done on
> both sides, I can't see why we shouldn't have tests that span across
> projects.
>
> Clearly, the sanitizer tests need Clang and Compiler-RT. Some Libc++
> tests need Compiler-RT, others need libunwind, on ARM I need Clang to
> build it. There are a lot of dependencies that are not there by
> accident, but by design.
>
> The more you move tests away from the big targets (LLVM, Clang), the
> less they're ran by people committing patches, and the harder will be
> to pick up the failures. Having said that, a decent buildbot coverage
> would account for most of those problems, but it would also put a
> stress on slow/expensive/experimental hardware support. It's a
> balance, I think.
>

Why would it require slow/expensive/experimental hardware? (& if it does
require that, how do you expect average developers to run them on a regular
basis?)


>
>
> > (it would mean that at least the pure (or at least non-Clang) LLVM
> developer
> > would have a test to run where they would not if the test remained in
> Clang
> > only)
>
> That is a good point. Right now, RT/libc++ tests in that category are
> controlled by enabling/disabling support via CMake flags. We may be
> able to do the same with Clang (if LLVM is not built with it, disable
> asm/obj tests). Moving them all to a regression package in the
> test-suite would be another option, but one that would take a lot
> longer...
>
> cheers,
> --renato
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[James Molloy via cfe-commits]

Hi,

FWIW, I'm happy with moving these tests into the test-suite. They do make
sense to be expressed in a compiler-neutral manner, even though some may
test clang-specific behaviour.

There is a UnitTests directory already, and adding the ability to run LIT
tests should be simple within the new CMake framework.

James
On Tue, 1 Dec 2015 at 19:09, David Blaikie  wrote:

> On Tue, Dec 1, 2015 at 10:43 AM, Renato Golin 
> wrote:
>
>> On 1 December 2015 at 18:29, David Blaikie  wrote:
>> > Are they things the test-suite couldn't (either technically or
>> > philosophically) cover, or only that it doesn't cover it at the moment,
>> but
>> > could do so?
>>
>> IMO, it's a philosophical issue. The test-suite is a whole-program
>> execution, and all that matters is the end result, the output of the
>> program, not the program itself.
>>
>> Those tests are mostly large (> 3 lines of code) so, if we were trying
>> to objdump and match for instruction patterns, any optimisation
>> variance could destroy them, as well as you may find the pattern
>> elsewhere in the same object, not belonging to the function you want
>> (inlining, etc).
>
>
> Not sure I follow - I'm not suggesting adding objdump/instruction checking
> to existing large programs in the test-suite, but adding other tests to the
> test-suite that do this and have appropriate input for it to be a
> reliable/useful form of testing.
>
>
>> All in all, all the problems with reducing C code
>> would be pertinent here, so a big hammer to kill small issues. On the
>> other hand, the Clang based asm/obj examples are all small, and
>> hand-crafted to suit the problem being tested.
>>
>> We could, however, add a new directory in the test-suite for that kind
>> of tests, like we already have for regressions in C/C++.
>
>
> If a separate directory makes it more clear what the purpose is, sure,
> seems fine to me, but I don't have strong or informed opinions on exactly
> how the test-suite is laid out.
>
>
>> That would
>> dissociate the front-end from the back-end, and essentially any
>> compiler used would have to abide by the rules of the test (which may
>> not be true for some compilers).
>>
>
> This is perhaps an interesting part/point: In theory I would think that
> these tests should be able to be phrased in a compiler-agnostic way, since
> they're testing the compiler as a whole and testing behavior that the
> source code demands, no?
>
>
>> I don't mind where they end up, really, but we need that kind of test
>> somewhere. Clang is an easy place because we know we have it built
>> when the Clang repo is checked out.
>>
>>
>> > That would sort of defeat the point of having the testing and projects
>> > separated though - it would tie the tests together and produce most of
>> the
>> > undesirable outcomes of having single end-to-end tests.
>>
>> Right, I agree, but since the relationship between Clang and LLVM is
>> non-trivial, and there are lots of changes that need to be done on
>> both sides, I can't see why we shouldn't have tests that span across
>> projects.
>>
>> Clearly, the sanitizer tests need Clang and Compiler-RT. Some Libc++
>> tests need Compiler-RT, others need libunwind, on ARM I need Clang to
>> build it. There are a lot of dependencies that are not there by
>> accident, but by design.
>>
>> The more you move tests away from the big targets (LLVM, Clang), the
>> less they're ran by people committing patches, and the harder will be
>> to pick up the failures. Having said that, a decent buildbot coverage
>> would account for most of those problems, but it would also put a
>> stress on slow/expensive/experimental hardware support. It's a
>> balance, I think.
>>
>
> Why would it require slow/expensive/experimental hardware? (& if it does
> require that, how do you expect average developers to run them on a regular
> basis?)
>
>
>>
>>
>> > (it would mean that at least the pure (or at least non-Clang) LLVM
>> developer
>> > would have a test to run where they would not if the test remained in
>> Clang
>> > only)
>>
>> That is a good point. Right now, RT/libc++ tests in that category are
>> controlled by enabling/disabling support via CMake flags. We may be
>> able to do the same with Clang (if LLVM is not built with it, disable
>> asm/obj tests). Moving them all to a regression package in the
>> test-suite would be another option, but one that would take a lot
>> longer...
>>
>> cheers,
>> --renato
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[Eric Christopher via cfe-commits]

On Tue, Dec 1, 2015 at 10:45 AM Eric Christopher  wrote:

> On Tue, Dec 1, 2015 at 10:43 AM James Molloy via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Hi,
>>
>> > That would sort of defeat the point of having the testing and projects
>> separated though - it would tie the tests together and produce most of the
>> undesirable outcomes of having single end-to-end tests.
>>
>> End to end tests have significant disadvantages as we all know. However
>> they do have some advantages too( that I have already enumerated) and the
>> question currently as I see it is how do we best get/keep those advantages
>> in our testing strategy?
>>
>> W.r.t the test-suite, that is a possibility. There are currently no
>> codegen-filecheck tests in the test-suite but there seems to be no reason I
>> can see why not. The disadvantage there for me is that we take short
>> running, simple tests and demote them to be run less often.
>>
>> Would it make sense to have a dedicated subdirectory in clang/test for
>> these kind of tests, so they can be directly enumerated and therefore kept
>> to a minimum , yet be allowed when they add value?
>>
>>
> There are a few cases where we can't currently test something, but none of
> the cases you or Renato have brought up qualify. I'm curious what you'd put
> in this directory?
>
>
FWIW to elaborate here on a place I know we can't test well at the moment
is the creation of the TargetMachine itself. This is why I've been trying
to pull as much stuff out of the API call and put it into the IR where
possible. It's a lot of refactoring to keep it particularly clean which is
why it's slow going.

-eric


> -eric
>
>
>> James
>> On Tue, 1 Dec 2015 at 18:29, David Blaikie  wrote:
>>
>>> On Tue, Dec 1, 2015 at 9:56 AM, Renato Golin via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 On 1 December 2015 at 17:23, James Molloy via cfe-commits
  wrote:
 > This isn't just a NEON intrinsics thing, and this isn't just an
 ARM/AArch64
 > thing. There needs to be some way to test the compiler from start to
 finish.
 > Not being able to do so leaves serious coverage holes.

 Just for the sake of completeness, a hole that the test-suite doesn't
 cover.

>>>
>>> Are they things the test-suite couldn't (either technically or
>>> philosophically) cover, or only that it doesn't cover it at the moment, but
>>> could do so?
>>>
>>>


 > CodeGen/aarch64-fix-cortex-a53-835769.c, where we absolutely 100% must
 > ensure that the -mfix-cortex-a53-835769 flag gets properly respected
 in the
 > compiler output.

 SIMD intrinsics (including NEON, SSE), Errata fixes, Procedure call
 tests, ELF section placement, FP contracts, Debug info, Inline
 assembly, Unicode support, object creation, library symbol clashes,
 back-end diagnostics are some of the examples that need to go all the
 way to asm or object code.


 > If you can describe a way to get the same strength of testing without
 > running the backend during clang tests, I'm all ears!

 I'm particularly interested in how do we keep the IR printed in the
 Clang tests in sync with the IR sent to the LLVM tests if/when they
 change, to guarantee that Clang changes don't generate silent codegen
 faults down the line in LLVM and vice-versa.

>>>
>>> That would sort of defeat the point of having the testing and projects
>>> separated though - it would tie the tests together and produce most of the
>>> undesirable outcomes of having single end-to-end tests.
>>>
>>> (it would mean that at least the pure (or at least non-Clang) LLVM
>>> developer would have a test to run where they would not if the test
>>> remained in Clang only)
>>>
>>>

 cheers,
 --renato
>>>
>>>
 ___
 cfe-commits mailing list
 cfe-commits@lists.llvm.org
 http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

>>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[Renato Golin via cfe-commits]

On 1 December 2015 at 19:09, David Blaikie  wrote:
> Not sure I follow - I'm not suggesting adding objdump/instruction checking
> to existing large programs in the test-suite, but adding other tests to the
> test-suite that do this and have appropriate input for it to be a
> reliable/useful form of testing.

Sorry, I was building to that... But currently, the test-suite
compiles the code into an executable, then run it. Changing that
premise means we'll have something other than the test-suite we always
had, and may bring other problems, like too many hats for the
infrastructure to keep, especially now that James is moving it to
integrate with lit. We may decide this is the way to go, but we need
to make clear all the pros and cons of doing so beforehand.


> This is perhaps an interesting part/point: In theory I would think that
> these tests should be able to be phrased in a compiler-agnostic way, since
> they're testing the compiler as a whole and testing behavior that the source
> code demands, no?

There's where things get interesting. Say we change the test-suite to
instead of compiling and running, just compile to asm/obj and
grep/objdump to match instructions, ELF sections, debug symbols, etc.

Some tests are easy to make compiler independent. Intrinsics tests
fall into that category. Most currently in Clang tests could move
directly to the test-suite as soon as we have such infrastructure.

Other tests, however, are specific to Clang+LLVM that may make no
sense to GCC or ICC, ARMCC etc. Those tests, would have to be in yet
another separate directory, that is only enabled if the compiler is
Clang, assuming the back-end is always LLVM.

These are all options that, for me, have equal value with keeping them
in Clang. AFAICS, they stir the same kind of problems wherever they
are tested.


>> would account for most of those problems, but it would also put a
>> stress on slow/expensive/experimental hardware support. It's a
>> balance, I think.
>
> Why would it require slow/expensive/experimental hardware? (& if it does
> require that, how do you expect average developers to run them on a regular
> basis?)

You misunderstood. It would "put a stress on", not "require".
Basically, it would increase the cost of testing on those classes of
hardware more than off-the-shelf hardware by a non-trivial amount.

This goes back to our discussion on buildbots, where some targets are
harder to find hardware than others, and when you do, they're slower.
Meaning the more variations we need to test, the more hardware you
have to have to make it in any reasonable time. While a single 64-core
Xeon can cope with most testing (including self-hosting, test-suite,
sanitizers, libc++) on a per-commit basis, there is nothing similar,
widely available, today for most other targets.

But that's another discussion entirely, let's not dwell into that again. :)

cheers,
--renato
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[James Molloy via cfe-commits]

Hi Renato,

> by a non-trivial amount.

Why do you think it would be non trivial? Some simple lit tests aren't
exactly arduous on most targets.

James
On Tue, 1 Dec 2015 at 19:39, Renato Golin  wrote:

> On 1 December 2015 at 19:09, David Blaikie  wrote:
> > Not sure I follow - I'm not suggesting adding objdump/instruction
> checking
> > to existing large programs in the test-suite, but adding other tests to
> the
> > test-suite that do this and have appropriate input for it to be a
> > reliable/useful form of testing.
>
> Sorry, I was building to that... But currently, the test-suite
> compiles the code into an executable, then run it. Changing that
> premise means we'll have something other than the test-suite we always
> had, and may bring other problems, like too many hats for the
> infrastructure to keep, especially now that James is moving it to
> integrate with lit. We may decide this is the way to go, but we need
> to make clear all the pros and cons of doing so beforehand.
>
>
> > This is perhaps an interesting part/point: In theory I would think that
> > these tests should be able to be phrased in a compiler-agnostic way,
> since
> > they're testing the compiler as a whole and testing behavior that the
> source
> > code demands, no?
>
> There's where things get interesting. Say we change the test-suite to
> instead of compiling and running, just compile to asm/obj and
> grep/objdump to match instructions, ELF sections, debug symbols, etc.
>
> Some tests are easy to make compiler independent. Intrinsics tests
> fall into that category. Most currently in Clang tests could move
> directly to the test-suite as soon as we have such infrastructure.
>
> Other tests, however, are specific to Clang+LLVM that may make no
> sense to GCC or ICC, ARMCC etc. Those tests, would have to be in yet
> another separate directory, that is only enabled if the compiler is
> Clang, assuming the back-end is always LLVM.
>
> These are all options that, for me, have equal value with keeping them
> in Clang. AFAICS, they stir the same kind of problems wherever they
> are tested.
>
>
> >> would account for most of those problems, but it would also put a
> >> stress on slow/expensive/experimental hardware support. It's a
> >> balance, I think.
> >
> > Why would it require slow/expensive/experimental hardware? (& if it does
> > require that, how do you expect average developers to run them on a
> regular
> > basis?)
>
> You misunderstood. It would "put a stress on", not "require".
> Basically, it would increase the cost of testing on those classes of
> hardware more than off-the-shelf hardware by a non-trivial amount.
>
> This goes back to our discussion on buildbots, where some targets are
> harder to find hardware than others, and when you do, they're slower.
> Meaning the more variations we need to test, the more hardware you
> have to have to make it in any reasonable time. While a single 64-core
> Xeon can cope with most testing (including self-hosting, test-suite,
> sanitizers, libc++) on a per-commit basis, there is nothing similar,
> widely available, today for most other targets.
>
> But that's another discussion entirely, let's not dwell into that again. :)
>
> cheers,
> --renato
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[David Blaikie via cfe-commits]

On Tue, Dec 1, 2015 at 11:39 AM, Renato Golin 
wrote:

> On 1 December 2015 at 19:09, David Blaikie  wrote:
> > Not sure I follow - I'm not suggesting adding objdump/instruction
> checking
> > to existing large programs in the test-suite, but adding other tests to
> the
> > test-suite that do this and have appropriate input for it to be a
> > reliable/useful form of testing.
>
> Sorry, I was building to that... But currently, the test-suite
> compiles the code into an executable, then run it. Changing that
> premise means we'll have something other than the test-suite we always
> had, and may bring other problems, like too many hats for the
> infrastructure to keep, especially now that James is moving it to
> integrate with lit. We may decide this is the way to go, but we need
> to make clear all the pros and cons of doing so beforehand.
>
>
> > This is perhaps an interesting part/point: In theory I would think that
> > these tests should be able to be phrased in a compiler-agnostic way,
> since
> > they're testing the compiler as a whole and testing behavior that the
> source
> > code demands, no?
>
> There's where things get interesting. Say we change the test-suite to
> instead of compiling and running, just compile to asm/obj and
> grep/objdump to match instructions, ELF sections, debug symbols, etc.
>
> Some tests are easy to make compiler independent. Intrinsics tests
> fall into that category. Most currently in Clang tests could move
> directly to the test-suite as soon as we have such infrastructure.
>
> Other tests, however, are specific to Clang+LLVM that may make no
> sense to GCC or ICC, ARMCC etc. Those tests, would have to be in yet
> another separate directory, that is only enabled if the compiler is
> Clang, assuming the back-end is always LLVM.
>

These cases I don't understand - if they're features LLVM supports we'd
just test them straight up. If you run our test suite against another
compiler it should tell you if it's compatible with our compiler (does it
offer the same functionality), so we don't have to maintain a distinction
between functionality we support and other compilers support, and
functionality we support and no other compiler support.

If the test isn't testing observable functionality, but some implementation
detail, that's a separate question and one I'd probably say shouldn't go in
the test-suite.


> These are all options that, for me, have equal value with keeping them
> in Clang. AFAICS, they stir the same kind of problems wherever they
> are tested.
>
>
> >> would account for most of those problems, but it would also put a
> >> stress on slow/expensive/experimental hardware support. It's a
> >> balance, I think.
> >
> > Why would it require slow/expensive/experimental hardware? (& if it does
> > require that, how do you expect average developers to run them on a
> regular
> > basis?)
>
> You misunderstood. It would "put a stress on", not "require".
> Basically, it would increase the cost of testing on those classes of
> hardware more than off-the-shelf hardware by a non-trivial amount.
>
> This goes back to our discussion on buildbots, where some targets are
> harder to find hardware than others, and when you do, they're slower.
> Meaning the more variations we need to test, the more hardware you
> have to have to make it in any reasonable time. While a single 64-core
> Xeon can cope with most testing (including self-hosting, test-suite,
> sanitizers, libc++) on a per-commit basis, there is nothing similar,
> widely available, today for most other targets.
>
> But that's another discussion entirely, let's not dwell into that again. :)
>

If you say so :)

- Dave


>
> cheers,
> --renato
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[James Molloy via cfe-commits]

Ok, understood.

I think I'd be OK with demoting these tests to the test-suite, and dealing
with the slightly lower amount of testing that comes with it if it means we
can keep the clang tests in a nice shape.

We'd need to ensure there were equivalent tests written that test only
clang produced IR - many tests will have this already but some don't.

James
On Tue, 1 Dec 2015 at 19:51, Renato Golin  wrote:

> On 1 December 2015 at 19:42, James Molloy  wrote:
> > Why do you think it would be non trivial? Some simple lit tests aren't
> > exactly arduous on most targets.
>
> I mean having more points in the testing matrix.
>
> Clang check-all is cheaper than running the test-suite, but if we
> start moving more tests to the suite, we'll have to run it for more
> combinations. For slow targets, that mostly means a new buildbot,
> because you want the "fast" check-all to not be impeded by the "slow"
> test-suite for every commit.
>
> The "non-trivial" amount is the sole difference in how many machines
> you can get to have a reasonable amount of commits in the blame-list
> for everything we test, which is trivial on fast x86_64 servers.
>
> --renato
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[Renato Golin via cfe-commits]

On 1 December 2015 at 19:53, James Molloy  wrote:
> I think I'd be OK with demoting these tests to the test-suite, and dealing
> with the slightly lower amount of testing that comes with it if it means we
> can keep the clang tests in a nice shape.

If the tests are independent of sub-architecture and instruction set, then yes.

If not, it means we'll have to have one test-suite per ISA / sub-arch
combination, in the same way we already (try to) have one Clang+LLVM
for each. This shows how it can go exponential.

cheers,
--renato
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[Renato Golin via cfe-commits]

On 1 December 2015 at 11:44, James Molloy via cfe-commits
 wrote:
> In summary, I agree with you that we need tests for both Clang and LLVM
> separately. However I also think the full-trip tests add significant value
> and wouldn't like to see them removed, and there's significant prior art in
> this area so if we did decide they needed to be gone, we'd need a good
> discussion on how to regain the testing coverage we'd lose.

I agree with James on all accounts. IR tests need to be written, but
assembly tests in Clang are not a bad idea at all.

You can have a Clang test to IR and an LLVM test form IR to assembly,
but if these IRs are not the same (because time passes, people forget
about updating tests), then you have a serious problem that you can't
see.

Having assembly tests in Clang mean that the right instructions are
being picked from the right high-level C code. If Clang stops
producing them, especially in the case of SIMD, then the patch who
broke it needs fixing or reverting.

I'd only make one observation regarding -O3 vs. a specific list of
passes. Each way has its own faults and I'm not particularly pending
to either one, but one has to consider what -O3 means and what you
really want. If you want vectorization, or hard-fp, then you should
ask them by name. If all you want is "optimal" code, and the source is
simple enough that it'd be impossible not to get them, then -O3 should
suffice.

cheers,
--renato
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[James Molloy via cfe-commits]

Hi Eric,

While I agree with you in principle, Alexandros has just pointed out to me
that all the other NEON intrinsics have such -O3 tests, and thinking about
it I do think they add value. They test the full-trip through the compiler
and ensure that Clang and LLVM have matching ideas of the IR interface
exposed by the intrinsics.

AIUI, Alexandros wrote LLVM backend tests in addition to these. It does
look like there are no tests just checking Clang's IR output - I think
these should indeed be written.

In summary, I agree with you that we need tests for both Clang and LLVM
separately. However I also think the full-trip tests add significant value
and wouldn't like to see them removed, and there's significant prior art in
this area so if we did decide they needed to be gone, we'd need a good
discussion on how to regain the testing coverage we'd lose.

Cheers,

James

On Sun, 29 Nov 2015 at 20:40 Eric Christopher via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Hi,
>
> This is entirely the wrong way to do these tests. They shouldn't depend on
> assembly output or optimization. Please split them onto frontend IR tests
> and backend assembly tests.
>
> Thanks!
>
> On Sun, Nov 29, 2015, 2:56 AM Alexandros Lamprineas via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: alelab01
>> Date: Sun Nov 29 04:53:28 2015
>> New Revision: 254251
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=254251=rev
>> Log:
>> ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply
>> Add/Subtract.
>>
>> Add missing tests that accidentally were not committed in rL254250.
>>
>> Differential Revision: http://reviews.llvm.org/D14982
>>
>> Added:
>> cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c
>> cfe/trunk/test/CodeGen/arm-v8.1a-neon-intrinsics.c
>>
>> Added: cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c?rev=254251=auto
>>
>> ==
>> --- cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c (added)
>> +++ cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c Sun Nov 29
>> 04:53:28 2015
>> @@ -0,0 +1,128 @@
>> +// REQUIRES: aarch64-registered-target
>> +
>> +// RUN: %clang_cc1 -triple aarch64-linux-gnu -target-feature +neon \
>> +// RUN:  -target-feature +v8.1a -O3 -S -o - %s \
>> +// RUN:  | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-AARCH64
>> +
>> + #include 
>> +
>> +// CHECK-AARCH64-LABEL: test_vqrdmlah_laneq_s16
>> +int16x4_t test_vqrdmlah_laneq_s16(int16x4_t a, int16x4_t b, int16x8_t v)
>> {
>> +// CHECK-AARCH64: sqrdmlah {{v[0-9]+}}.4h, {{v[0-9]+}}.4h,
>> {{v[0-9]+}}.h[7]
>> +  return vqrdmlah_laneq_s16(a, b, v, 7);
>> +}
>> +
>> +// CHECK-AARCH64-LABEL: test_vqrdmlah_laneq_s32
>> +int32x2_t test_vqrdmlah_laneq_s32(int32x2_t a, int32x2_t b, int32x4_t v)
>> {
>> +// CHECK-AARCH64: sqrdmlah {{v[0-9]+}}.2s, {{v[0-9]+}}.2s,
>> {{v[0-9]+}}.s[3]
>> +  return vqrdmlah_laneq_s32(a, b, v, 3);
>> +}
>> +
>> +// CHECK-AARCH64-LABEL: test_vqrdmlahq_laneq_s16
>> +int16x8_t test_vqrdmlahq_laneq_s16(int16x8_t a, int16x8_t b, int16x8_t
>> v) {
>> +// CHECK-AARCH64: sqrdmlah {{v[0-9]+}}.8h, {{v[0-9]+}}.8h,
>> {{v[0-9]+}}.h[7]
>> +  return vqrdmlahq_laneq_s16(a, b, v, 7);
>> +}
>> +
>> +// CHECK-AARCH64-LABEL: test_vqrdmlahq_laneq_s32
>> +int32x4_t test_vqrdmlahq_laneq_s32(int32x4_t a, int32x4_t b, int32x4_t
>> v) {
>> +// CHECK-AARCH64: sqrdmlah {{v[0-9]+}}.4s, {{v[0-9]+}}.4s,
>> {{v[0-9]+}}.s[3]
>> +  return vqrdmlahq_laneq_s32(a, b, v, 3);
>> +}
>> +
>> +// CHECK-AARCH64-LABEL: test_vqrdmlahh_s16
>> +int16_t test_vqrdmlahh_s16(int16_t a, int16_t b, int16_t c) {
>> +// CHECK-AARCH64: sqrdmlah {{h[0-9]+|v[0-9]+.4h}},
>> {{h[0-9]+|v[0-9]+.4h}}, {{h[0-9]+|v[0-9]+.4h}}
>> +  return vqrdmlahh_s16(a, b, c);
>> +}
>> +
>> +// CHECK-AARCH64-LABEL: test_vqrdmlahs_s32
>> +int32_t test_vqrdmlahs_s32(int32_t a, int32_t b, int32_t c) {
>> +// CHECK-AARCH64: sqrdmlah {{s[0-9]+}}, {{s[0-9]+}}, {{s[0-9]+}}
>> +  return vqrdmlahs_s32(a, b, c);
>> +}
>> +
>> +// CHECK-AARCH64-LABEL: test_vqrdmlahh_lane_s16
>> +int16_t test_vqrdmlahh_lane_s16(int16_t a, int16_t b, int16x4_t c) {
>> +// CHECK-AARCH64: sqrdmlah {{h[0-9]+|v[0-9]+.4h}},
>> {{h[0-9]+|v[0-9]+.4h}}, {{v[0-9]+}}.h[3]
>> +  return vqrdmlahh_lane_s16(a, b, c, 3);
>> +}
>> +
>> +// CHECK-AARCH64-LABEL: test_vqrdmlahs_lane_s32
>> +int32_t test_vqrdmlahs_lane_s32(int32_t a, int32_t b, int32x2_t c) {
>> +// CHECK-AARCH64: sqrdmlah {{s[0-9]+}}, {{s[0-9]+}}, {{v[0-9]+}}.s[1]
>> +  return vqrdmlahs_lane_s32(a, b, c, 1);
>> +}
>> +
>> +// CHECK-AARCH64-LABEL: test_vqrdmlahh_laneq_s16
>> +int16_t test_vqrdmlahh_laneq_s16(int16_t a, int16_t b, int16x8_t c) {
>> +// CHECK-AARCH64: sqrdmlah {{h[0-9]+|v[0-9]+.4h}},
>> {{h[0-9]+|v[0-9]+.4h}}, {{v[0-9]+}}.h[7]
>> +  return vqrdmlahh_laneq_s16(a, b, c, 7);
>> +}
>> +
>> +// CHECK-AARCH64-LABEL: test_vqrdmlahs_laneq_s32

Re: r254251 - ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply

[Eric Christopher via cfe-commits]

Hi,

This is entirely the wrong way to do these tests. They shouldn't depend on
assembly output or optimization. Please split them onto frontend IR tests
and backend assembly tests.

Thanks!

On Sun, Nov 29, 2015, 2:56 AM Alexandros Lamprineas via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: alelab01
> Date: Sun Nov 29 04:53:28 2015
> New Revision: 254251
>
> URL: http://llvm.org/viewvc/llvm-project?rev=254251=rev
> Log:
> ARM v8.1a adds Advanced SIMD instructions for Rounding Double Multiply
> Add/Subtract.
>
> Add missing tests that accidentally were not committed in rL254250.
>
> Differential Revision: http://reviews.llvm.org/D14982
>
> Added:
> cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c
> cfe/trunk/test/CodeGen/arm-v8.1a-neon-intrinsics.c
>
> Added: cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c?rev=254251=auto
>
> ==
> --- cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c (added)
> +++ cfe/trunk/test/CodeGen/aarch64-v8.1a-neon-intrinsics.c Sun Nov 29
> 04:53:28 2015
> @@ -0,0 +1,128 @@
> +// REQUIRES: aarch64-registered-target
> +
> +// RUN: %clang_cc1 -triple aarch64-linux-gnu -target-feature +neon \
> +// RUN:  -target-feature +v8.1a -O3 -S -o - %s \
> +// RUN:  | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-AARCH64
> +
> + #include 
> +
> +// CHECK-AARCH64-LABEL: test_vqrdmlah_laneq_s16
> +int16x4_t test_vqrdmlah_laneq_s16(int16x4_t a, int16x4_t b, int16x8_t v) {
> +// CHECK-AARCH64: sqrdmlah {{v[0-9]+}}.4h, {{v[0-9]+}}.4h,
> {{v[0-9]+}}.h[7]
> +  return vqrdmlah_laneq_s16(a, b, v, 7);
> +}
> +
> +// CHECK-AARCH64-LABEL: test_vqrdmlah_laneq_s32
> +int32x2_t test_vqrdmlah_laneq_s32(int32x2_t a, int32x2_t b, int32x4_t v) {
> +// CHECK-AARCH64: sqrdmlah {{v[0-9]+}}.2s, {{v[0-9]+}}.2s,
> {{v[0-9]+}}.s[3]
> +  return vqrdmlah_laneq_s32(a, b, v, 3);
> +}
> +
> +// CHECK-AARCH64-LABEL: test_vqrdmlahq_laneq_s16
> +int16x8_t test_vqrdmlahq_laneq_s16(int16x8_t a, int16x8_t b, int16x8_t v)
> {
> +// CHECK-AARCH64: sqrdmlah {{v[0-9]+}}.8h, {{v[0-9]+}}.8h,
> {{v[0-9]+}}.h[7]
> +  return vqrdmlahq_laneq_s16(a, b, v, 7);
> +}
> +
> +// CHECK-AARCH64-LABEL: test_vqrdmlahq_laneq_s32
> +int32x4_t test_vqrdmlahq_laneq_s32(int32x4_t a, int32x4_t b, int32x4_t v)
> {
> +// CHECK-AARCH64: sqrdmlah {{v[0-9]+}}.4s, {{v[0-9]+}}.4s,
> {{v[0-9]+}}.s[3]
> +  return vqrdmlahq_laneq_s32(a, b, v, 3);
> +}
> +
> +// CHECK-AARCH64-LABEL: test_vqrdmlahh_s16
> +int16_t test_vqrdmlahh_s16(int16_t a, int16_t b, int16_t c) {
> +// CHECK-AARCH64: sqrdmlah {{h[0-9]+|v[0-9]+.4h}},
> {{h[0-9]+|v[0-9]+.4h}}, {{h[0-9]+|v[0-9]+.4h}}
> +  return vqrdmlahh_s16(a, b, c);
> +}
> +
> +// CHECK-AARCH64-LABEL: test_vqrdmlahs_s32
> +int32_t test_vqrdmlahs_s32(int32_t a, int32_t b, int32_t c) {
> +// CHECK-AARCH64: sqrdmlah {{s[0-9]+}}, {{s[0-9]+}}, {{s[0-9]+}}
> +  return vqrdmlahs_s32(a, b, c);
> +}
> +
> +// CHECK-AARCH64-LABEL: test_vqrdmlahh_lane_s16
> +int16_t test_vqrdmlahh_lane_s16(int16_t a, int16_t b, int16x4_t c) {
> +// CHECK-AARCH64: sqrdmlah {{h[0-9]+|v[0-9]+.4h}},
> {{h[0-9]+|v[0-9]+.4h}}, {{v[0-9]+}}.h[3]
> +  return vqrdmlahh_lane_s16(a, b, c, 3);
> +}
> +
> +// CHECK-AARCH64-LABEL: test_vqrdmlahs_lane_s32
> +int32_t test_vqrdmlahs_lane_s32(int32_t a, int32_t b, int32x2_t c) {
> +// CHECK-AARCH64: sqrdmlah {{s[0-9]+}}, {{s[0-9]+}}, {{v[0-9]+}}.s[1]
> +  return vqrdmlahs_lane_s32(a, b, c, 1);
> +}
> +
> +// CHECK-AARCH64-LABEL: test_vqrdmlahh_laneq_s16
> +int16_t test_vqrdmlahh_laneq_s16(int16_t a, int16_t b, int16x8_t c) {
> +// CHECK-AARCH64: sqrdmlah {{h[0-9]+|v[0-9]+.4h}},
> {{h[0-9]+|v[0-9]+.4h}}, {{v[0-9]+}}.h[7]
> +  return vqrdmlahh_laneq_s16(a, b, c, 7);
> +}
> +
> +// CHECK-AARCH64-LABEL: test_vqrdmlahs_laneq_s32
> +int32_t test_vqrdmlahs_laneq_s32(int32_t a, int32_t b, int32x4_t c) {
> +// CHECK-AARCH64: sqrdmlah {{s[0-9]+}}, {{s[0-9]+}}, {{v[0-9]+}}.s[3]
> +  return vqrdmlahs_laneq_s32(a, b, c, 3);
> +}
> +
> +// CHECK-AARCH64-LABEL: test_vqrdmlsh_laneq_s16
> +int16x4_t test_vqrdmlsh_laneq_s16(int16x4_t a, int16x4_t b, int16x8_t v) {
> +// CHECK-AARCH64: sqrdmlsh {{v[0-9]+}}.4h, {{v[0-9]+}}.4h,
> {{v[0-9]+}}.h[7]
> +  return vqrdmlsh_laneq_s16(a, b, v, 7);
> +}
> +
> +// CHECK-AARCH64-LABEL: test_vqrdmlsh_laneq_s32
> +int32x2_t test_vqrdmlsh_laneq_s32(int32x2_t a, int32x2_t b, int32x4_t v) {
> +// CHECK-AARCH64: sqrdmlsh {{v[0-9]+}}.2s, {{v[0-9]+}}.2s,
> {{v[0-9]+}}.s[3]
> +  return vqrdmlsh_laneq_s32(a, b, v, 3);
> +}
> +
> +// CHECK-AARCH64-LABEL: test_vqrdmlshq_laneq_s16
> +int16x8_t test_vqrdmlshq_laneq_s16(int16x8_t a, int16x8_t b, int16x8_t v)
> {
> +// CHECK-AARCH64: sqrdmlsh {{v[0-9]+}}.8h, {{v[0-9]+}}.8h,
> {{v[0-9]+}}.h[7]
> +  return vqrdmlshq_laneq_s16(a, b, v, 7);
> +}
> +
> +// CHECK-AARCH64-LABEL: test_vqrdmlshq_laneq_s32
> +int32x4_t test_vqrdmlshq_laneq_s32(int32x4_t a,