diff mbox

[ARM] Fix testsuite testcase neon-vcond-[ltgt,unordered].c

Message ID 526855F7.6040309@linaro.org
State Superseded
Headers show

Commit Message

Kugan Vivekanandarajah Oct. 23, 2013, 11:04 p.m. UTC
Hi,

arm testcases neon-vcond-ltgt.c and neon-vcond-unordered.c fails in
Linaro 4.8 branch. It is not reproducable with trunk but it can happen.
Both neon-vcond-ltgt.c and neon-vcond-unordered.c scans for vbsl
instruction, with other vector instructions. However, as per the comment
 for "neon_vbsl<mode>_internal" md pattern defined in neon.md, gcc can
generate vbsl or vbit or vbif depending on the register allocation.
Therfore, these testcases should scan for one of these three
instructions instead of just vbsl. I have updated the testcases to scan
vbsl or vbit or vbif now.

Is this OK?

Thanks,
Kugan

2013-10-23  Kugan Vivekanandarajah  <kuganv@linaro.org>
	* gcc.target/arm/neon-vcond-ltgt.c: Scan for vbsl or vbit or vbif.
	* gcc.target/arm/neon-vcond-unordered.c: Scan for vbsl or vbit or vbif.

Comments

Kyrylo Tkachov Oct. 24, 2013, 2:39 p.m. UTC | #1
On 24/10/13 00:04, Kugan wrote:
> Hi,
>
> arm testcases neon-vcond-ltgt.c and neon-vcond-unordered.c fails in
> Linaro 4.8 branch. It is not reproducable with trunk but it can happen.
> Both neon-vcond-ltgt.c and neon-vcond-unordered.c scans for vbsl
> instruction, with other vector instructions. However, as per the comment
>   for "neon_vbsl<mode>_internal" md pattern defined in neon.md, gcc can
> generate vbsl or vbit or vbif depending on the register allocation.
> Therfore, these testcases should scan for one of these three
> instructions instead of just vbsl. I have updated the testcases to scan
> vbsl or vbit or vbif now.
>
> Is this OK?
>
> Thanks,
> Kugan
>
> 2013-10-23  Kugan Vivekanandarajah  <kuganv@linaro.org>
> 	* gcc.target/arm/neon-vcond-ltgt.c: Scan for vbsl or vbit or vbif.
> 	* gcc.target/arm/neon-vcond-unordered.c: Scan for vbsl or vbit or vbif.
Hi Kugan,

Hmmm... What about neon-vcond-gt.c? Could it conceivably start up using vbsl or 
vbif as the register allocator changes (I assume this different allocation is 
happening because of LRA?)

Otherwise looks sensible to me, but I cannot approve it.

Thanks,
Kyrill
Christophe Lyon Oct. 24, 2013, 2:52 p.m. UTC | #2
Hi Kyrill,

Kugan only fixes the tests we have observed to fail.
The different allocation is not caused by LRA, since we haven't
backported it to our 4.8-based branch.
The different allocation is caused by another difference between 4.8 and trunk.

Christophe.


On 24 October 2013 16:39, Kyrill Tkachov <kyrylo.tkachov@arm.com> wrote:
> On 24/10/13 00:04, Kugan wrote:
>>
>> Hi,
>>
>> arm testcases neon-vcond-ltgt.c and neon-vcond-unordered.c fails in
>> Linaro 4.8 branch. It is not reproducable with trunk but it can happen.
>> Both neon-vcond-ltgt.c and neon-vcond-unordered.c scans for vbsl
>> instruction, with other vector instructions. However, as per the comment
>>   for "neon_vbsl<mode>_internal" md pattern defined in neon.md, gcc can
>> generate vbsl or vbit or vbif depending on the register allocation.
>> Therfore, these testcases should scan for one of these three
>> instructions instead of just vbsl. I have updated the testcases to scan
>> vbsl or vbit or vbif now.
>>
>> Is this OK?
>>
>> Thanks,
>> Kugan
>>
>> 2013-10-23  Kugan Vivekanandarajah  <kuganv@linaro.org>
>>         * gcc.target/arm/neon-vcond-ltgt.c: Scan for vbsl or vbit or vbif.
>>         * gcc.target/arm/neon-vcond-unordered.c: Scan for vbsl or vbit or
>> vbif.
>
> Hi Kugan,
>
> Hmmm... What about neon-vcond-gt.c? Could it conceivably start up using vbsl
> or vbif as the register allocator changes (I assume this different
> allocation is happening because of LRA?)
>
> Otherwise looks sensible to me, but I cannot approve it.
>
> Thanks,
> Kyrill
>
>
Kyrylo Tkachov Oct. 24, 2013, 4:52 p.m. UTC | #3
On 24/10/13 15:52, Christophe Lyon wrote:
> Hi Kyrill,
>
> Kugan only fixes the tests we have observed to fail.
> The different allocation is not caused by LRA, since we haven't
> backported it to our 4.8-based branch.
> The different allocation is caused by another difference between 4.8 and trunk.
I can't seem to get it to fail on my checkout of the linaro 4.8 branch. I tried 
both arm-none-eabi and arm-none-linux-gnueabihf. What kind of 
options/configuration are needed to reproduce this? Also, what kind of assembly 
is produced when the testcase fails? It'd be nice to make sure that the 
allocator doesn't end up doing something sub-optimal and unnecessarily moving 
stuff around to satisfy the alternative constraints that produce the other 
bit-select variants.

Kyrill

>
> Christophe.
>
>
> On 24 October 2013 16:39, Kyrill Tkachov <kyrylo.tkachov@arm.com> wrote:
>> On 24/10/13 00:04, Kugan wrote:
>>> Hi,
>>>
>>> arm testcases neon-vcond-ltgt.c and neon-vcond-unordered.c fails in
>>> Linaro 4.8 branch. It is not reproducable with trunk but it can happen.
>>> Both neon-vcond-ltgt.c and neon-vcond-unordered.c scans for vbsl
>>> instruction, with other vector instructions. However, as per the comment
>>>    for "neon_vbsl<mode>_internal" md pattern defined in neon.md, gcc can
>>> generate vbsl or vbit or vbif depending on the register allocation.
>>> Therfore, these testcases should scan for one of these three
>>> instructions instead of just vbsl. I have updated the testcases to scan
>>> vbsl or vbit or vbif now.
>>>
>>> Is this OK?
>>>
>>> Thanks,
>>> Kugan
>>>
>>> 2013-10-23  Kugan Vivekanandarajah  <kuganv@linaro.org>
>>>          * gcc.target/arm/neon-vcond-ltgt.c: Scan for vbsl or vbit or vbif.
>>>          * gcc.target/arm/neon-vcond-unordered.c: Scan for vbsl or vbit or
>>> vbif.
>> Hi Kugan,
>>
>> Hmmm... What about neon-vcond-gt.c? Could it conceivably start up using vbsl
>> or vbif as the register allocator changes (I assume this different
>> allocation is happening because of LRA?)
>>
>> Otherwise looks sensible to me, but I cannot approve it.
>>
>> Thanks,
>> Kyrill
>>
>>
Ramana Radhakrishnan Oct. 29, 2013, 9:36 a.m. UTC | #4
On 10/24/13 00:04, Kugan wrote:
> Hi,
>
> arm testcases neon-vcond-ltgt.c and neon-vcond-unordered.c fails in
> Linaro 4.8 branch. It is not reproducable with trunk but it can happen.
> Both neon-vcond-ltgt.c and neon-vcond-unordered.c scans for vbsl
> instruction, with other vector instructions. However, as per the comment
>   for "neon_vbsl<mode>_internal" md pattern defined in neon.md, gcc can
> generate vbsl or vbit or vbif depending on the register allocation.
> Therfore, these testcases should scan for one of these three
> instructions instead of just vbsl. I have updated the testcases to scan
> vbsl or vbit or vbif now.
>
> Is this OK?

This is OK. Thanks for the analysis on the testcase.

regards
Ramana

>
> Thanks,
> Kugan
>
> 2013-10-23  Kugan Vivekanandarajah  <kuganv@linaro.org>
> 	* gcc.target/arm/neon-vcond-ltgt.c: Scan for vbsl or vbit or vbif.
> 	* gcc.target/arm/neon-vcond-unordered.c: Scan for vbsl or vbit or vbif.
>
>
Ramana Radhakrishnan Oct. 29, 2013, 9:38 a.m. UTC | #5
On 10/24/13 00:04, Kugan wrote:
> Hi,
>
> arm testcases neon-vcond-ltgt.c and neon-vcond-unordered.c fails in
> Linaro 4.8 branch. It is not reproducable with trunk but it can happen.
> Both neon-vcond-ltgt.c and neon-vcond-unordered.c scans for vbsl
> instruction, with other vector instructions. However, as per the comment
>   for "neon_vbsl<mode>_internal" md pattern defined in neon.md, gcc can
> generate vbsl or vbit or vbif depending on the register allocation.
> Therfore, these testcases should scan for one of these three
> instructions instead of just vbsl. I have updated the testcases to scan
> vbsl or vbit or vbif now.
>
> Is this OK?
>
> Thanks,
> Kugan


Hit send too soon on my earlier email. Minor nit in the Changelog as 
below. Need a newline between the DATE line and the file names .

>
> 2013-10-23  Kugan Vivekanandarajah  <kuganv@linaro.org>

> 	* gcc.target/arm/neon-vcond-ltgt.c: Scan for vbsl or vbit or vbif.
> 	* gcc.target/arm/neon-vcond-unordered.c: Scan for vbsl or vbit or vbif.
>
>


Ramana
Christophe Lyon Nov. 3, 2013, 9:48 p.m. UTC | #6
On 29 October 2013 10:38, Ramana Radhakrishnan <ramrad01@arm.com> wrote:
> On 10/24/13 00:04, Kugan wrote:
>>
>> Hi,
>>
>> arm testcases neon-vcond-ltgt.c and neon-vcond-unordered.c fails in
>> Linaro 4.8 branch. It is not reproducable with trunk but it can happen.
>> Both neon-vcond-ltgt.c and neon-vcond-unordered.c scans for vbsl
>> instruction, with other vector instructions. However, as per the comment
>>   for "neon_vbsl<mode>_internal" md pattern defined in neon.md, gcc can
>> generate vbsl or vbit or vbif depending on the register allocation.
>> Therfore, these testcases should scan for one of these three
>> instructions instead of just vbsl. I have updated the testcases to scan
>> vbsl or vbit or vbif now.
>>
>> Is this OK?
>>
>> Thanks,
>> Kugan
>
>
>
> Hit send too soon on my earlier email. Minor nit in the Changelog as below.
> Need a newline between the DATE line and the file names .
>
>
Committed on Kugan's behalf as rev 204336.

Christophe.
diff mbox

Patch

diff --git a/gcc/testsuite/gcc.target/arm/neon-vcond-ltgt.c b/gcc/testsuite/gcc.target/arm/neon-vcond-ltgt.c
index acb23a9..c8306e3 100644
--- a/gcc/testsuite/gcc.target/arm/neon-vcond-ltgt.c
+++ b/gcc/testsuite/gcc.target/arm/neon-vcond-ltgt.c
@@ -15,4 +15,4 @@  void foo (int ilast,float* w, float* w2)
 
 /* { dg-final { scan-assembler-times "vcgt\\.f32\[\\t \]*q\[0-9\]+,\[\\t \]*q\[0-9\]+,\[\\t \]*q\[0-9\]+" 2 } } */
 /* { dg-final { scan-assembler "vorr\[\\t \]*q\[0-9\]+,\[\\t \]*q\[0-9\]+,\[\\t \]*q\[0-9\]+" } } */
-/* { dg-final { scan-assembler "vbsl\[\\t \]*q\[0-9\]+,\[\\t \]*q\[0-9\]+,\[\\t \]*q\[0-9\]+" } } */
+/* { dg-final { scan-assembler "vbsl|vbit|vbif\[\\t \]*q\[0-9\]+,\[\\t \]*q\[0-9\]+,\[\\t \]*q\[0-9\]+" } } */
diff --git a/gcc/testsuite/gcc.target/arm/neon-vcond-unordered.c b/gcc/testsuite/gcc.target/arm/neon-vcond-unordered.c
index c3e448d..3bb67d3 100644
--- a/gcc/testsuite/gcc.target/arm/neon-vcond-unordered.c
+++ b/gcc/testsuite/gcc.target/arm/neon-vcond-unordered.c
@@ -16,4 +16,4 @@  void foo (int ilast,float* w, float* w2)
 /* { dg-final { scan-assembler "vcgt\\.f32\[\\t \]*q\[0-9\]+,\[\\t \]*q\[0-9\]+,\[\\t \]*q\[0-9\]+" } } */
 /* { dg-final { scan-assembler "vcge\\.f32\[\\t \]*q\[0-9\]+,\[\\t \]*q\[0-9\]+,\[\\t \]*q\[0-9\]+" } } */
 /* { dg-final { scan-assembler "vorr\[\\t \]*q\[0-9\]+,\[\\t \]*q\[0-9\]+,\[\\t \]*q\[0-9\]+" } } */
-/* { dg-final { scan-assembler "vbsl\[\\t \]*q\[0-9\]+,\[\\t \]*q\[0-9\]+,\[\\t \]*q\[0-9\]+" } } */
+/* { dg-final { scan-assembler "vbsl|vbit|vbif\[\\t \]*q\[0-9\]+,\[\\t \]*q\[0-9\]+,\[\\t \]*q\[0-9\]+" } } */