[ARM] PR66791: Replace calls to builtin in vmul_n (a, b) intrinsics with __a * __b

Prathamesh Kulkarni prathamesh.kulkarni@linaro.org
Tue Jun 29 07:21:50 GMT 2021


On Mon, 21 Jun 2021 at 14:04, Prathamesh Kulkarni
<prathamesh.kulkarni@linaro.org> wrote:
>
> On Mon, 14 Jun 2021 at 13:27, Prathamesh Kulkarni
> <prathamesh.kulkarni@linaro.org> wrote:
> >
> > On Mon, 7 Jun 2021 at 12:45, Prathamesh Kulkarni
> > <prathamesh.kulkarni@linaro.org> wrote:
> > >
> > > On Mon, 31 May 2021 at 16:01, Prathamesh Kulkarni
> > > <prathamesh.kulkarni@linaro.org> wrote:
> > > >
> > > > On Mon, 31 May 2021 at 15:22, Prathamesh Kulkarni
> > > > <prathamesh.kulkarni@linaro.org> wrote:
> > > > >
> > > > > On Wed, 26 May 2021 at 14:07, Marc Glisse <marc.glisse@inria.fr> wrote:
> > > > > >
> > > > > > On Wed, 26 May 2021, Prathamesh Kulkarni via Gcc-patches wrote:
> > > > > >
> > > > > > > The attached patch removes calls to builtins in vmul_n* (a, b) with __a * __b.
> > > > > >
> > > > > > I am not familiar with neon, but are __a and __b unsigned here? Otherwise,
> > > > > > is vmul_n already undefined in case of overflow?
> > > > > Hi Marc,
> > > > > Sorry for late reply, for vmul_n_s*, I think they are signed
> > > > > (int<width>x<width>_t).
> > > > Oops, I meant int<width>x<nelems>_t.
> > > > > I am not sure how should the intrinsic behave in case of signed overflow,
> > > > > but I am assuming it's OK since vmul_s* intrinsics leave it undefined too.
> > > > > Kyrill, is it OK to leave vmul_s* and vmul_n_s* undefined in case of overflow ?
> > > The attached version fixes one fallout I missed earlier.
> > > Is this OK to commit ?
> > ping https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572037.html
> ping * 2 https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572037.html
ping * 3 https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572037.html

Thanks,
Prathamesh
>
> Thanks,
> Prathamesh
> >
> > Thanks,
> > Prathamesh
> > >
> > > Thanks,
> > > Prathamesh
> > > > >
> > > > > Thanks,
> > > > > Prathamesh
> > > > > >
> > > > > > --
> > > > > > Marc Glisse


More information about the Gcc-patches mailing list