On Thu, 6 Jun 2019 at 16:54, Richard Sandiford wrote: > > Szabolcs Nagy writes: > > On 03/06/2019 08:26, Prathamesh Kulkarni wrote: > >> +++ b/gcc/testsuite/gcc.target/aarch64/sve/init_8.c > >> @@ -0,0 +1,32 @@ > >> +/* { dg-do assemble { target aarch64_asm_sve_ok } } */ > >> +/* { dg-options "-O2 -fno-schedule-insns -msve-vector-bits=256 --save-temps" } */ > >> + > >> +/* Case 5.2: Interleaved elements and constants. */ > >> + > >> +#include > >> + > >> +typedef int32_t vnx4si __attribute__((vector_size (32))); > >> + > >> +__attribute__((noipa)) > >> +vnx4si foo(int a, int b, int c, int d) > >> +{ > >> + return (vnx4si) { a, 1, b, 2, c, 3, d, 4 }; > >> +} > >> + > >> +/* > >> +foo: > >> +.LFB0: > >> + .cfi_startproc > >> + ptrue p0.s, vl8 > >> + mov z0.s, w3 > >> + adrp x3, .LANCHOR0 > >> + insr z0.s, w2 > >> + add x3, x3, :lo12:.LANCHOR0 > >> + insr z0.s, w1 > >> + ld1w z1.s, p0/z, [x3] > >> + insr z0.s, w0 > >> + zip1 z0.s, z0.s, z1.s > >> + ret > >> +*/ > >> + > >> +/* { dg-final { scan-assembler {\tmov\t(z[0-9]+\.s), w3\n\tadrp\t(x[0-9]+), \.LANCHOR0\n\tinsr\t\1, w2\n\tadd\t\2, \2, :lo12:\.LANCHOR0\n\tinsr\t\1, w1\n\tld1w\t(z[0-9]+\.s), p[0-9]+/z, \[\2\]\n\tinsr\t\1, w0\n\tzip1\t\1, \1, \3} } } */ > > > > this fails with tiny model when i'm testing aarch64-none-elf > > > > $ make check-c 'RUNTESTFLAGS=--target_board=aarch64-elf-qemu{-mcmodel=tiny} aarch64-sve.exp=init_8.c' > > ... > > FAIL: gcc.target/aarch64/sve/init_8.c -march=armv8.2-a+sve scan-assembler \\tmov\\t(z[0-9]+\\.s), w3\\n\\tadrp\\t(x[0-9]+), > > \\.LANCHOR0\\n\\tinsr\\t\\1, w2\\n\\tadd\\t\\2, \\2, :lo12:\\.LANCHOR0\\n\\tinsr\\t\\1, w1\\n\\tld1w\\t(z[0-9]+\\.s), p[0-9]+/z, > > \\[\\2\\]\\n\\tinsr\\t\\1, w0\\n\\tzip1\\t\\1, \\1, \\3 > > > > i think you need conditional scan asm for { target aarch64_small } > > and { target aarch64_tiny } or just skip the test for tiny, > > Maybe we should remove the address calculation and replace the ld1w > address with \[[^]]*\]. All that really matters for this test is that > the vector is loaded from memory. > > > but even then matching exact register name and instruction scheduling > > seems fragile. > > The only hard-coded register names are the parameters, which are > guaranteed by the ABI. Testing for those should be fine. > > The dg-options pass -fno-schedule-insns, but I guess they should > also pass -fno-schedule-insns2. Or maybe just use -O instead. > We can always revisit this later if even that isn't enough to make > the order stable. Thanks for the suggestions. Passing -fno-schedule-insns2 does seem to make the order stable. For init_1.c to init_4.c there were no intervening instructions, and for remaining tests, the patch passes -fno-schedule-insns2 and adjusts dg-scan accordingly. I verified the tests pass with -mcmodel=tiny. OK to commit ? Thanks, Prathamesh > > Richard