> -Original Message-
> From: Gcc-patches On Behalf Of
> Richard Sandiford via Gcc-patches
> Sent: 10 December 2020 17:54
> To: Christophe Lyon
> Cc: Christophe Lyon via Gcc-patches
> Subject: Re: RFC: ARM MVE and Neon auto-vectorization
>
> Christophe Lyon
Christophe Lyon writes:
> On Wed, 9 Dec 2020 at 17:47, Richard Sandiford
> wrote:
>>
>> Christophe Lyon via Gcc-patches 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
>> > mu
On Wed, 9 Dec 2020 at 17:47, Richard Sandiford
wrote:
>
> Christophe Lyon via Gcc-patches 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 se
Christophe Lyon via Gcc-patches 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 hav
On 08/12/2020 13:50, Christophe Lyon via Gcc-patches wrote:
Hi,
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
