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