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
