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 '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. So.... I guess my question is: do we want to enforce implementation of Neon / MVE common parts? There are already lots of partly overlapping/duplicate iterators. I have tried to split iterators into eg VDQ_COMMON_TO_NEON_AND_MVE and VDQ_NEON_ONLY but this means we have to basically duplicate the expanders which defeats the point... Or we can keep different expanders for Neon and MVE? But we have already quite a few in vec-common.md. I hoped I could submit more vectorization patches for MVE, but it seems there's more preparation work needed. Any advice highly appreciated! Thanks, Christophe