Re: [AArch64] [SVE] PR88837 - Poor vector construction code in VL-specific mode

[Richard Sandiford <richard.sandiford@arm.com>]

Szabolcs Nagy <Szabolcs.Nagy@arm.com> 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 <stdint.h>
>> +
>> +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.

Richard