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.tkac...@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 <kug...@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 > >