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.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
