| Message ID | 526855F7.6040309@linaro.org |
|---|---|
| State | New |
| Headers | show |
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
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 > >
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 >> >>
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. > >
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
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 --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\]+" } } */