[PATCH][PING] Vectorize conversions directly

Ramana Radhakrishnan ramana.radhakrishnan@linaro.org
Tue Nov 22 14:04:00 GMT 2011


Sorry , it's taken me a while to get to this.

On 28 October 2011 09:22, Dmitry Plotnikov <dplotnikov@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

>



More information about the Gcc-patches mailing list