RFC: ARM MVE and Neon auto-vectorization

[Richard Sandiford]

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