Christophe Lyon via Gcc-patches <gcc-patches@gcc.gnu.org> writes: > Hi, > > I've been working for a while on enabling auto-vectorization for ARM > MVE, and I find it a bit awkward to keep things common with Neon as > much as possible. > > I've just sent a few patches for logical operators > (vand/vorr/veor/vbic), and I have a few more WIP patches where I > struggle to avoid duplication. > > For example, vneg is supported in different modes by MVE and Neon: > * Neon: VDQ and VH iterators: V8QI V16QI V4HI V8HI V2SI V4SI V4HF V8HF > V2SF V4SF V2DI and V8HF V4HF > * MVE: MVE_2 and MVE_0 iterators: V16QI V8HI V4SI and V8HF V4SF
My hope behind the ARM_HAVE_<MODE>_<FOO> macros was that the common (optab) define_expand could use those, with the most permissive iterator necessary. We could stick on a "&& !TARGET_IWMMXT" for things that aren't implemented for iwMMXt. The above combination seems like a natural fit for unmodified VDQ with ARM_HAVE_<MODE>_ARITH. This would be similar to the existing add<mode>3 pattern. > My 'vand' patch changes the definition of VDQ so that the relevant > modes are enabled only when !TARGET_HAVE_MVE (V8QI, ...), and this > helps writing a simpler expander. > > However, vneg is used by vshr (right-shifts by register are > implemented as left-shift by negation of that register), so the > expander uses something like: > > emit_insn (gen_neg<mode>2 (neg, operands[2])); > if (TARGET_NEON) > emit_insn (gen_ashl<mode>3_signed (operands[0], operands[1], neg)); > else > emit_insn (gen_mve_vshlq_s<mode> (operands[0], operands[1], neg)); > > which does not work if the iterator has conditional members: the > 'else' part is still generated for <mode> unsupported by MVE. FWIW, I agree with Andre that it would be good to remove unnecessary NEON/MVE differences like this. Another technique that can be used where necessary is to convert: gen_foo<mode> (args) to: gen_foo (mode, args) and add a @ to the start of the definition of pattern "foo". Thanks, Richard
