On Wed, 9 Dec 2020 at 17:47, Richard Sandiford
<richard.sandif...@arm.com> wrote:
>
> 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.
>

OK, so it looks like I should revert/fix my just-committed vand patch,
and restore the unconditional definition of VDQ and use
ARM_HAVE_<MODE>_ARITH for the expander?

> > 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.
>
OK thanks for the feedback, I'll update my other patches along these
lines. Too bad this will delay auto-vectorization improvement more
than I hoped :-(

> 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".

Ha, indeed, thanks!

> Thanks,
> Richard

Reply via email to