Prathamesh Kulkarni <prathamesh.kulka...@linaro.org> writes:
> Hi Richard,
> For the following (contrived) test:
>
> void foo(int32x4_t v)
> {
> v[3] = 0;
> return v;
> }
>
> -O2 code-gen:
> foo:
> fmov s1, wzr
> ins v0.s[3], v1.s[0]
> ret
>
> I suppose we can instead emit the following code-gen ?
> foo:
> ins v0.s[3], wzr
> ret
>
> combine produces:
> Failed to match this instruction:
> (set (reg:V4SI 95 [ v ])
> (vec_merge:V4SI (const_vector:V4SI [
> (const_int 0 [0]) repeated x4
> ])
> (reg:V4SI 97)
> (const_int 8 [0x8])))
>
> So, I wrote the following pattern to match the above insn:
> (define_insn "aarch64_simd_vec_set_zero<mode>"
> [(set (match_operand:VALL_F16 0 "register_operand" "=w")
> (vec_merge:VALL_F16
> (match_operand:VALL_F16 1 "const_dup0_operand" "w")
> (match_operand:VALL_F16 3 "register_operand" "0")
> (match_operand:SI 2 "immediate_operand" "i")))]
> "TARGET_SIMD"
> {
> int elt = ENDIAN_LANE_N (<nunits>, exact_log2 (INTVAL (operands[2])));
> operands[2] = GEN_INT ((HOST_WIDE_INT) 1 << elt);
> return "ins\\t%0.<Vetype>[%p2], wzr";
> }
> )
>
> which now matches the above insn produced by combine.
> However, in reload dump, it creates a new insn for assigning
> register to (const_vector (const_int 0)),
> which results in:
> (insn 19 8 13 2 (set (reg:V4SI 33 v1 [99])
> (const_vector:V4SI [
> (const_int 0 [0]) repeated x4
> ])) "wzr-test.c":8:1 1269 {*aarch64_simd_movv4si}
> (nil))
> (insn 13 19 14 2 (set (reg/i:V4SI 32 v0)
> (vec_merge:V4SI (reg:V4SI 33 v1 [99])
> (reg:V4SI 32 v0 [97])
> (const_int 8 [0x8]))) "wzr-test.c":8:1 1808
> {aarch64_simd_vec_set_zerov4si}
> (nil))
>
> and eventually the code-gen:
> foo:
> movi v1.4s, 0
> ins v0.s[3], wzr
> ret
>
> To get rid of redundant assignment of 0 to v1, I tried to split the
> above pattern
> as in the attached patch. This works to emit code-gen:
> foo:
> ins v0.s[3], wzr
> ret
>
> However, I am not sure if this is the right approach. Could you suggest,
> if it'd be possible to get rid of UNSPEC_SETZERO in the patch ?
The problem is with the "w" constraint on operand 1, which tells LRA
to force the zero into an FPR. It should work if you remove the
constraint.
Also, I think you'll need to use <vwcore>zr for the zero, so that
it uses xzr for 64-bit elements.
I think this and the existing patterns ought to test
exact_log2 (INTVAL (operands[2])) >= 0 in the insn condition,
since there's no guarantee that RTL optimisations won't form
vec_merges that have other masks.
Thanks,
Richard
