| Message ID | 5ABA4980.4000802@foss.arm.com |
|---|---|
| State | New |
| Headers | show |
| Series | [AArch64] XFAIL gcc.target/aarch64/store_v2vec_lanes.c for ILP32 | expand |
On Tue, Mar 27, 2018 at 02:39:12PM +0100, Kyrill Tkachov wrote: > Hi all, > > The test in question fails for ilp32. The initial analysis I did in the PR for it > is that for ILP32 we generate somewhat different address forms that we'd need to adjust aarch64_classify_address to catch. > Given the optimisation this test checks for was added for GCC 8 it is not a regression, and improving the codegen on ILP32 > would be an enhancement rather than a fix. So Richi has asked for it to be marked as XFAIL on ILP32, which is what this > patch does. > Checked that the test still passes on LP64 and appears as XFAIL on -mabi=ilp32. > > Ok for trunk? This would count under the obvious rule. OK. Thanks, James > Thanks, > Kyrill > > 2018-03-27 Kyrylo Tkachov <kyrylo.tkachov@arm.com> > > PR target/83009 > * gcc.target/aarch64/store_v2vec_lanes.c: XFAIL for ilp32. > commit 39e1ef03918b1911cedae37552cbaf1185420aa2 > Author: Kyrylo Tkachov <kyrylo.tkachov@arm.com> > Date: Tue Mar 27 10:45:04 2018 +0100 > > [AArch64] XFAIL gcc.target/aarch64/store_v2vec_lanes.c for ILP32 > > diff --git a/gcc/testsuite/gcc.target/aarch64/store_v2vec_lanes.c b/gcc/testsuite/gcc.target/aarch64/store_v2vec_lanes.c > index 6810db3..990aea3 100644 > --- a/gcc/testsuite/gcc.target/aarch64/store_v2vec_lanes.c > +++ b/gcc/testsuite/gcc.target/aarch64/store_v2vec_lanes.c > @@ -26,6 +26,6 @@ construct_lane_2 (long long *y, v2di *z) > values from consecutive memory into a 2-element vector by using > a Q-reg LDR. */ > > -/* { dg-final { scan-assembler-times "stp\td\[0-9\]+, d\[0-9\]+" 1 } } */ > -/* { dg-final { scan-assembler-times "stp\tx\[0-9\]+, x\[0-9\]+" 1 } } */ > -/* { dg-final { scan-assembler-not "ins\t" } } */ > +/* { dg-final { scan-assembler-times "stp\td\[0-9\]+, d\[0-9\]+" 1 { xfail ilp32 } } } */ > +/* { dg-final { scan-assembler-times "stp\tx\[0-9\]+, x\[0-9\]+" 1 { xfail ilp32 } } } */ > +/* { dg-final { scan-assembler-not "ins\t" { xfail ilp32 } } } */
commit 39e1ef03918b1911cedae37552cbaf1185420aa2
Author: Kyrylo Tkachov <kyrylo.tkachov@arm.com>
Date: Tue Mar 27 10:45:04 2018 +0100
[AArch64] XFAIL gcc.target/aarch64/store_v2vec_lanes.c for ILP32
diff --git a/gcc/testsuite/gcc.target/aarch64/store_v2vec_lanes.c b/gcc/testsuite/gcc.target/aarch64/store_v2vec_lanes.c
index 6810db3..990aea3 100644
--- a/gcc/testsuite/gcc.target/aarch64/store_v2vec_lanes.c
+++ b/gcc/testsuite/gcc.target/aarch64/store_v2vec_lanes.c
@@ -26,6 +26,6 @@ construct_lane_2 (long long *y, v2di *z)
values from consecutive memory into a 2-element vector by using
a Q-reg LDR. */
-/* { dg-final { scan-assembler-times "stp\td\[0-9\]+, d\[0-9\]+" 1 } } */
-/* { dg-final { scan-assembler-times "stp\tx\[0-9\]+, x\[0-9\]+" 1 } } */
-/* { dg-final { scan-assembler-not "ins\t" } } */
+/* { dg-final { scan-assembler-times "stp\td\[0-9\]+, d\[0-9\]+" 1 { xfail ilp32 } } } */
+/* { dg-final { scan-assembler-times "stp\tx\[0-9\]+, x\[0-9\]+" 1 { xfail ilp32 } } } */
+/* { dg-final { scan-assembler-not "ins\t" { xfail ilp32 } } } */
Hi all, The test in question fails for ilp32. The initial analysis I did in the PR for it is that for ILP32 we generate somewhat different address forms that we'd need to adjust aarch64_classify_address to catch. Given the optimisation this test checks for was added for GCC 8 it is not a regression, and improving the codegen on ILP32 would be an enhancement rather than a fix. So Richi has asked for it to be marked as XFAIL on ILP32, which is what this patch does. Checked that the test still passes on LP64 and appears as XFAIL on -mabi=ilp32. Ok for trunk? Thanks, Kyrill 2018-03-27 Kyrylo Tkachov <kyrylo.tkachov@arm.com> PR target/83009 * gcc.target/aarch64/store_v2vec_lanes.c: XFAIL for ilp32.