Sorry , it's taken me a while to get to this. On 28 October 2011 09:22, Dmitry Plotnikov <dplotni...@ispras.ru> wrote: > > gcc/config/arm/ > * neon.md (floatv2siv2sf2): New. > (floatunsv2siv2sf2): New. > (fix_truncv2sfv2si2): New. > (fix_truncunsv2sfv2si2): New. > (floatv4siv4sf2): New. > (floatunsv4siv4sf2): New. > (fix_truncv4sfv4si2): New. > (fix_truncunsv4sfv4si2): New.
It would have been better to write these in the iterator forms as well as is the style in all neon.md. Also, you are missing neon_type attributes - therefore these would be treated as being standard ALU instructions rather than the neon instructions and hence would flow through the ALU pipeline description . In the V2SI / V2SF case, these instructions should have a neon_type of neon_fp_vadd_ddd_vabs_dd and the V4SI / V4SF case treat them as having a neon type of neon_fp_vadd_qqq_vabs_qq. For bonus points integrate this with the patterns already defined for the neon intrinsics expansion and thus essentially remove the UNSPEC's from the neon_vcvt<mode> patterns. Thus essentially converting your define_insn patterns to define_expands and massaging the whole thing through. > > gcc/testsuite/ > * gcc.target/arm/vect-vcvt.c: New test. > * gcc.target/arm/vect-vcvtq.c: New test. There's no need for -mvectorize-with-neon-quad in the tests. That is the default these days on trunk. > > gcc/testsuite/lib/ > * target-supports.exp (check_effective_target_vect_intfloat_cvt): True > for ARM NEON. > (check_effective_target_vect_uintfloat_cvt): Likewise. > (check_effective_target_vect_intfloat_cvt): Likewise. > (check_effective_target_vect_floatuint_cvt): Likewise. > (check_effective_target_vect_floatint_cvt): Likewise. > (check_effective_target_vect_extract_even_odd): Likewise. I'm not sure about enabling the vect_extract_even_odd case. If this assumes the presence of an extract-even-odd from registers type operation, then the Neon port doesn't really support vec_extract_even / vec_extract_odd forms - You do have them in one single instruction if you tried to load them from / or store them to memory which is the vld2 / vst2 instruction while the register form of vuzp which reads and writes to both source operands is not really supported directly from the backend. The other testsuite changes look OK to me. cheers Ramana >