Hi,
For the following test-case:
int16x8_t foo(int16_t x, int16_t y)
{
return (int16x8_t) { x, y, x, y, x, y, x, y };
}
Code gen at -O3:
foo:
dupv0.8h, w0
ins v0.h[1], w1
ins v0.h[3], w1
ins v0.h[5], w1
ins v0.h[7], w1
ret
For
On Thu, 12 Jan 2023 at 21:21, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Tue, 6 Dec 2022 at 07:01, Prathamesh Kulkarni
> > wrote:
> >>
> >> On Mon, 5 Dec 2022 at 16:50, Richard Sandiford
> >> wrote:
> >> >
> >> > Richard Sandiford via Gcc-patches writes:
> >> > > Prathames
Prathamesh Kulkarni writes:
> On Thu, 12 Jan 2023 at 21:21, Richard Sandiford
> wrote:
>>
>> Prathamesh Kulkarni writes:
>> > On Tue, 6 Dec 2022 at 07:01, Prathamesh Kulkarni
>> > wrote:
>> >>
>> >> On Mon, 5 Dec 2022 at 16:50, Richard Sandiford
>> >> wrote:
>> >> >
>> >> > Richard Sandiford v
On Wed, 1 Feb 2023 at 21:56, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Thu, 12 Jan 2023 at 21:21, Richard Sandiford
> > wrote:
> >>
> >> Prathamesh Kulkarni writes:
> >> > On Tue, 6 Dec 2022 at 07:01, Prathamesh Kulkarni
> >> > wrote:
> >> >>
> >> >> On Mon, 5 Dec 2022 at
Prathamesh Kulkarni writes:
>> >> > I have attached a patch that extends the transform if one half is dup
>> >> > and other is set of constants.
>> >> > For eg:
>> >> > int8x16_t f(int8_t x)
>> >> > {
>> >> > return (int8x16_t) { x, 1, x, 2, x, 3, x, 4, x, 5, x, 6, x, 7, x, 8 };
>> >> > }
>> >>
On Thu, 2 Feb 2023 at 20:50, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> >> >> > I have attached a patch that extends the transform if one half is dup
> >> >> > and other is set of constants.
> >> >> > For eg:
> >> >> > int8x16_t f(int8_t x)
> >> >> > {
> >> >> > return (int8x16_
On Fri, 3 Feb 2023 at 07:10, Prathamesh Kulkarni
wrote:
>
> On Thu, 2 Feb 2023 at 20:50, Richard Sandiford
> wrote:
> >
> > Prathamesh Kulkarni writes:
> > >> >> > I have attached a patch that extends the transform if one half is
> > >> >> > dup
> > >> >> > and other is set of constants.
> > >>
Prathamesh Kulkarni writes:
> On Fri, 3 Feb 2023 at 07:10, Prathamesh Kulkarni
> wrote:
>>
>> On Thu, 2 Feb 2023 at 20:50, Richard Sandiford
>> wrote:
>> >
>> > Prathamesh Kulkarni writes:
>> > >> >> > I have attached a patch that extends the transform if one half is
>> > >> >> > dup
>> > >> >
On Fri, 3 Feb 2023 at 20:47, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Fri, 3 Feb 2023 at 07:10, Prathamesh Kulkarni
> > wrote:
> >>
> >> On Thu, 2 Feb 2023 at 20:50, Richard Sandiford
> >> wrote:
> >> >
> >> > Prathamesh Kulkarni writes:
> >> > >> >> > I have attached a
Prathamesh Kulkarni writes:
> On Fri, 3 Feb 2023 at 20:47, Richard Sandiford
> wrote:
>>
>> Prathamesh Kulkarni writes:
>> > On Fri, 3 Feb 2023 at 07:10, Prathamesh Kulkarni
>> > wrote:
>> >>
>> >> On Thu, 2 Feb 2023 at 20:50, Richard Sandiford
>> >> wrote:
>> >> >
>> >> > Prathamesh Kulkarni
On Mon, 6 Feb 2023 at 17:43, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Fri, 3 Feb 2023 at 20:47, Richard Sandiford
> > wrote:
> >>
> >> Prathamesh Kulkarni writes:
> >> > On Fri, 3 Feb 2023 at 07:10, Prathamesh Kulkarni
> >> > wrote:
> >> >>
> >> >> On Thu, 2 Feb 2023 at
On Tue, Nov 29, 2022 at 6:40 AM Prathamesh Kulkarni via Gcc-patches
wrote:
>
> Hi,
> For the following test-case:
>
> int16x8_t foo(int16_t x, int16_t y)
> {
> return (int16x8_t) { x, y, x, y, x, y, x, y };
> }
(Not to block this patch)
Seems like this trick can be done even with less than perf
On Tue, 29 Nov 2022 at 20:43, Andrew Pinski wrote:
>
> On Tue, Nov 29, 2022 at 6:40 AM Prathamesh Kulkarni via Gcc-patches
> wrote:
> >
> > Hi,
> > For the following test-case:
> >
> > int16x8_t foo(int16_t x, int16_t y)
> > {
> > return (int16x8_t) { x, y, x, y, x, y, x, y };
> > }
>
> (Not to
Prathamesh Kulkarni writes:
> Hi,
> For the following test-case:
>
> int16x8_t foo(int16_t x, int16_t y)
> {
> return (int16x8_t) { x, y, x, y, x, y, x, y };
> }
>
> Code gen at -O3:
> foo:
> dupv0.8h, w0
> ins v0.h[1], w1
> ins v0.h[3], w1
> ins v
Richard Sandiford via Gcc-patches writes:
> Prathamesh Kulkarni writes:
>> Hi,
>> For the following test-case:
>>
>> int16x8_t foo(int16_t x, int16_t y)
>> {
>> return (int16x8_t) { x, y, x, y, x, y, x, y };
>> }
>>
>> Code gen at -O3:
>> foo:
>> dupv0.8h, w0
>> ins v0.h
On Mon, 5 Dec 2022 at 16:50, Richard Sandiford
wrote:
>
> Richard Sandiford via Gcc-patches writes:
> > Prathamesh Kulkarni writes:
> >> Hi,
> >> For the following test-case:
> >>
> >> int16x8_t foo(int16_t x, int16_t y)
> >> {
> >> return (int16x8_t) { x, y, x, y, x, y, x, y };
> >> }
> >>
>
On Mon, 13 Mar 2023 at 13:03, Richard Biener wrote:
>
> On Fri, 10 Mar 2023, Richard Sandiford wrote:
>
> > Sorry for the slow reply.
> >
> > Prathamesh Kulkarni writes:
> > > Unfortunately it regresses code-gen for the following case:
> > >
> > > svint32_t f(int32x4_t x)
> > > {
> > > return s
Prathamesh Kulkarni writes:
> On Mon, 13 Mar 2023 at 13:03, Richard Biener wrote:
>> On GIMPLE it would be
>>
>> _1 = { a, ... }; // (a)
>> _2 = { _1, ... }; // (b)
>>
>> but I'm not sure if (b), a VL CTOR of fixed len(?) sub-vectors is
>> possible? But at least a CTOR of vectors is what we us
On Tue, 4 Apr 2023 at 23:35, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Mon, 13 Mar 2023 at 13:03, Richard Biener wrote:
> >> On GIMPLE it would be
> >>
> >> _1 = { a, ... }; // (a)
> >> _2 = { _1, ... }; // (b)
> >>
> >> but I'm not sure if (b), a VL CTOR of fixed len(?)
Prathamesh Kulkarni writes:
> On Tue, 4 Apr 2023 at 23:35, Richard Sandiford
> wrote:
>> > diff --git a/gcc/config/aarch64/aarch64-sve-builtins-base.cc
>> > b/gcc/config/aarch64/aarch64-sve-builtins-base.cc
>> > index cd9cace3c9b..3de79060619 100644
>> > --- a/gcc/config/aarch64/aarch64-sve-buil
On Thu, 6 Apr 2023 at 16:05, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Tue, 4 Apr 2023 at 23:35, Richard Sandiford
> > wrote:
> >> > diff --git a/gcc/config/aarch64/aarch64-sve-builtins-base.cc
> >> > b/gcc/config/aarch64/aarch64-sve-builtins-base.cc
> >> > index cd9cace3c
Prathamesh Kulkarni writes:
> On Thu, 6 Apr 2023 at 16:05, Richard Sandiford
> wrote:
>>
>> Prathamesh Kulkarni writes:
>> > On Tue, 4 Apr 2023 at 23:35, Richard Sandiford
>> > wrote:
>> >> > diff --git a/gcc/config/aarch64/aarch64-sve-builtins-base.cc
>> >> > b/gcc/config/aarch64/aarch64-sve-
On Wed, 12 Apr 2023 at 14:29, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Thu, 6 Apr 2023 at 16:05, Richard Sandiford
> > wrote:
> >>
> >> Prathamesh Kulkarni writes:
> >> > On Tue, 4 Apr 2023 at 23:35, Richard Sandiford
> >> > wrote:
> >> >> > diff --git a/gcc/config/aarch
Prathamesh Kulkarni writes:
> Hi,
> I tested the interleave+zip1 for vector init patch and it segfaulted
> during bootstrap while trying to build
> libgfortran/generated/matmul_i2.c.
> Rebuilding with --enable-checking=rtl showed out of bounds access in
> aarch64_unzip_vector_init in following hun
On Fri, 21 Apr 2023 at 14:47, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > Hi,
> > I tested the interleave+zip1 for vector init patch and it segfaulted
> > during bootstrap while trying to build
> > libgfortran/generated/matmul_i2.c.
> > Rebuilding with --enable-checking=rtl showe
On Fri, 21 Apr 2023 at 20:45, Prathamesh Kulkarni
wrote:
>
> On Fri, 21 Apr 2023 at 14:47, Richard Sandiford
> wrote:
> >
> > Prathamesh Kulkarni writes:
> > > Hi,
> > > I tested the interleave+zip1 for vector init patch and it segfaulted
> > > during bootstrap while trying to build
> > > libgfo
Prathamesh Kulkarni writes:
> [aarch64] Recursively intialize even and odd sub-parts and merge with zip1.
>
> gcc/ChangeLog:
> * config/aarch64/aarch64.cc (aarch64_expand_vector_init_fallback):
> Rename
> aarch64_expand_vector_init to this, and remove interleaving case.
> Recur
On Tue, 6 Dec 2022 at 07:01, Prathamesh Kulkarni
wrote:
>
> On Mon, 5 Dec 2022 at 16:50, Richard Sandiford
> wrote:
> >
> > Richard Sandiford via Gcc-patches writes:
> > > Prathamesh Kulkarni writes:
> > >> Hi,
> > >> For the following test-case:
> > >>
> > >> int16x8_t foo(int16_t x, int16_t y
Prathamesh Kulkarni writes:
> On Tue, 6 Dec 2022 at 07:01, Prathamesh Kulkarni
> wrote:
>>
>> On Mon, 5 Dec 2022 at 16:50, Richard Sandiford
>> wrote:
>> >
>> > Richard Sandiford via Gcc-patches writes:
>> > > Prathamesh Kulkarni writes:
>> > >> Hi,
>> > >> For the following test-case:
>> > >>
On Mon, 24 Apr 2023 at 15:00, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > [aarch64] Recursively intialize even and odd sub-parts and merge with zip1.
> >
> > gcc/ChangeLog:
> > * config/aarch64/aarch64.cc (aarch64_expand_vector_init_fallback):
> > Rename
> > aarch64_
Prathamesh Kulkarni writes:
> diff --git a/gcc/testsuite/gcc.target/aarch64/vec-init-18.c
> b/gcc/testsuite/gcc.target/aarch64/vec-init-18.c
> new file mode 100644
> index 000..598a51f17c6
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/vec-init-18.c
> @@ -0,0 +1,20 @@
> +/* { dg
On Fri, 12 May 2023 at 00:37, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > diff --git a/gcc/testsuite/gcc.target/aarch64/vec-init-18.c
> > b/gcc/testsuite/gcc.target/aarch64/vec-init-18.c
> > new file mode 100644
> > index 000..598a51f17c6
> > --- /dev/null
> > +++ b/gcc/
Sorry for the slow reply.
Prathamesh Kulkarni writes:
> Unfortunately it regresses code-gen for the following case:
>
> svint32_t f(int32x4_t x)
> {
> return svdupq_s32 (x[0], x[1], x[2], x[3]);
> }
>
> -O2 code-gen with trunk:
> f:
> dup z0.q, z0.q[0]
> ret
>
> -O2 code-gen
On Fri, 10 Mar 2023, Richard Sandiford wrote:
> Sorry for the slow reply.
>
> Prathamesh Kulkarni writes:
> > Unfortunately it regresses code-gen for the following case:
> >
> > svint32_t f(int32x4_t x)
> > {
> > return svdupq_s32 (x[0], x[1], x[2], x[3]);
> > }
> >
> > -O2 code-gen with trunk
34 matches
Mail list logo