Re: [ARM] PR98435: Missed optimization in expanding vector constructor

[Christophe Lyon <christophe.lyon.oss@gmail.com>]

On Mon, Aug 9, 2021 at 7:07 AM Prathamesh Kulkarni <
prathamesh.kulkarni@linaro.org> wrote:

> On Fri, 6 Aug 2021 at 17:31, Christophe Lyon
> <christophe.lyon.oss@gmail.com> wrote:
> >
> >
> >
> > On Fri, Aug 6, 2021 at 11:51 AM Prathamesh Kulkarni <
> prathamesh.kulkarni@linaro.org> wrote:
> >>
> >> On Fri, 6 Aug 2021 at 14:49, Christophe Lyon
> >> <christophe.lyon.oss@gmail.com> wrote:
> >> >
> >> >
> >> >
> >> > On Fri, Aug 6, 2021 at 11:00 AM Prathamesh Kulkarni <
> prathamesh.kulkarni@linaro.org> wrote:
> >> >>
> >> >> On Thu, 5 Aug 2021 at 18:05, Christophe Lyon
> >> >> <christophe.lyon.oss@gmail.com> wrote:
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Thu, Aug 5, 2021 at 2:28 PM Prathamesh Kulkarni <
> prathamesh.kulkarni@linaro.org> wrote:
> >> >> >>
> >> >> >> On Tue, 3 Aug 2021 at 20:52, Christophe Lyon
> >> >> >> <christophe.lyon.oss@gmail.com> wrote:
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > On Tue, Aug 3, 2021 at 12:57 PM Prathamesh Kulkarni <
> prathamesh.kulkarni@linaro.org> wrote:
> >> >> >> >>
> >> >> >> >> On Tue, 3 Aug 2021 at 14:59, Christophe Lyon
> >> >> >> >> <christophe.lyon.oss@gmail.com> wrote:
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> > On Tue, Jul 6, 2021 at 11:26 AM Prathamesh Kulkarni via
> Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
> >> >> >> >> >>
> >> >> >> >> >> On Tue, 6 Jul 2021 at 13:33, Kyrylo Tkachov <
> Kyrylo.Tkachov@arm.com> wrote:
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >> > > -----Original Message-----
> >> >> >> >> >> > > From: Prathamesh Kulkarni <
> prathamesh.kulkarni@linaro.org>
> >> >> >> >> >> > > Sent: 06 July 2021 08:06
> >> >> >> >> >> > > To: Christophe LYON <christophe.lyon@foss.st.com>
> >> >> >> >> >> > > Cc: Kyrylo Tkachov <Kyrylo.Tkachov@arm.com>; gcc
> Patches <gcc-
> >> >> >> >> >> > > patches@gcc.gnu.org>
> >> >> >> >> >> > > Subject: Re: [ARM] PR98435: Missed optimization in
> expanding vector
> >> >> >> >> >> > > constructor
> >> >> >> >> >> > >
> >> >> >> >> >> > > On Thu, 1 Jul 2021 at 16:26, Prathamesh Kulkarni
> >> >> >> >> >> > > <prathamesh.kulkarni@linaro.org> wrote:
> >> >> >> >> >> > > >
> >> >> >> >> >> > > > On Wed, 30 Jun 2021 at 20:51, Christophe LYON
> >> >> >> >> >> > > > <christophe.lyon@foss.st.com> wrote:
> >> >> >> >> >> > > > >
> >> >> >> >> >> > > > >
> >> >> >> >> >> > > > > On 29/06/2021 12:46, Prathamesh Kulkarni wrote:
> >> >> >> >> >> > > > > > On Mon, 28 Jun 2021 at 14:48, Christophe LYON
> >> >> >> >> >> > > > > > <christophe.lyon@foss.st.com> wrote:
> >> >> >> >> >> > > > > >>
> >> >> >> >> >> > > > > >> On 28/06/2021 10:40, Kyrylo Tkachov via
> Gcc-patches wrote:
> >> >> >> >> >> > > > > >>>> -----Original Message-----
> >> >> >> >> >> > > > > >>>> From: Prathamesh Kulkarni <
> prathamesh.kulkarni@linaro.org>
> >> >> >> >> >> > > > > >>>> Sent: 28 June 2021 09:38
> >> >> >> >> >> > > > > >>>> To: Kyrylo Tkachov <Kyrylo.Tkachov@arm.com>
> >> >> >> >> >> > > > > >>>> Cc: Christophe Lyon <
> christophe.lyon@linaro.org>; gcc Patches
> >> >> >> >> >> > > <gcc-
> >> >> >> >> >> > > > > >>>> patches@gcc.gnu.org>
> >> >> >> >> >> > > > > >>>> Subject: Re: [ARM] PR98435: Missed
> optimization in expanding
> >> >> >> >> >> > > vector
> >> >> >> >> >> > > > > >>>> constructor
> >> >> >> >> >> > > > > >>>>
> >> >> >> >> >> > > > > >>>> On Thu, 24 Jun 2021 at 22:01, Kyrylo Tkachov
> >> >> >> >> >> > > <Kyrylo.Tkachov@arm.com>
> >> >> >> >> >> > > > > >>>> wrote:
> >> >> >> >> >> > > > > >>>>>
> >> >> >> >> >> > > > > >>>>>> -----Original Message-----
> >> >> >> >> >> > > > > >>>>>> From: Prathamesh Kulkarni <
> prathamesh.kulkarni@linaro.org>
> >> >> >> >> >> > > > > >>>>>> Sent: 14 June 2021 09:02
> >> >> >> >> >> > > > > >>>>>> To: Christophe Lyon <
> christophe.lyon@linaro.org>
> >> >> >> >> >> > > > > >>>>>> Cc: gcc Patches <gcc-patches@gcc.gnu.org>;
> Kyrylo Tkachov
> >> >> >> >> >> > > > > >>>>>> <Kyrylo.Tkachov@arm.com>
> >> >> >> >> >> > > > > >>>>>> Subject: Re: [ARM] PR98435: Missed
> optimization in expanding
> >> >> >> >> >> > > vector
> >> >> >> >> >> > > > > >>>>>> constructor
> >> >> >> >> >> > > > > >>>>>>
> >> >> >> >> >> > > > > >>>>>> On Wed, 9 Jun 2021 at 15:58, Prathamesh
> Kulkarni
> >> >> >> >> >> > > > > >>>>>> <prathamesh.kulkarni@linaro.org> wrote:
> >> >> >> >> >> > > > > >>>>>>> On Fri, 4 Jun 2021 at 13:15, Christophe Lyon
> >> >> >> >> >> > > > > >>>> <christophe.lyon@linaro.org>
> >> >> >> >> >> > > > > >>>>>> wrote:
> >> >> >> >> >> > > > > >>>>>>>> On Fri, 4 Jun 2021 at 09:27, Prathamesh
> Kulkarni via Gcc-
> >> >> >> >> >> > > patches
> >> >> >> >> >> > > > > >>>>>>>> <gcc-patches@gcc.gnu.org> wrote:
> >> >> >> >> >> > > > > >>>>>>>>> Hi,
> >> >> >> >> >> > > > > >>>>>>>>> As mentioned in PR, for the following
> test-case:
> >> >> >> >> >> > > > > >>>>>>>>>
> >> >> >> >> >> > > > > >>>>>>>>> #include <arm_neon.h>
> >> >> >> >> >> > > > > >>>>>>>>>
> >> >> >> >> >> > > > > >>>>>>>>> bfloat16x4_t f1 (bfloat16_t a)
> >> >> >> >> >> > > > > >>>>>>>>> {
> >> >> >> >> >> > > > > >>>>>>>>>     return vdup_n_bf16 (a);
> >> >> >> >> >> > > > > >>>>>>>>> }
> >> >> >> >> >> > > > > >>>>>>>>>
> >> >> >> >> >> > > > > >>>>>>>>> bfloat16x4_t f2 (bfloat16_t a)
> >> >> >> >> >> > > > > >>>>>>>>> {
> >> >> >> >> >> > > > > >>>>>>>>>     return (bfloat16x4_t) {a, a, a, a};
> >> >> >> >> >> > > > > >>>>>>>>> }
> >> >> >> >> >> > > > > >>>>>>>>>
> >> >> >> >> >> > > > > >>>>>>>>> Compiling with arm-linux-gnueabi -O3
> -mfpu=neon -mfloat-
> >> >> >> >> >> > > > > >>>> abi=softfp
> >> >> >> >> >> > > > > >>>>>>>>> -march=armv8.2-a+bf16+fp16 results in f2
> not being
> >> >> >> >> >> > > vectorized:
> >> >> >> >> >> > > > > >>>>>>>>>
> >> >> >> >> >> > > > > >>>>>>>>> f1:
> >> >> >> >> >> > > > > >>>>>>>>>           vdup.16 d16, r0
> >> >> >> >> >> > > > > >>>>>>>>>           vmov    r0, r1, d16  @ v4bf
> >> >> >> >> >> > > > > >>>>>>>>>           bx      lr
> >> >> >> >> >> > > > > >>>>>>>>>
> >> >> >> >> >> > > > > >>>>>>>>> f2:
> >> >> >> >> >> > > > > >>>>>>>>>           mov     r3, r0  @ __bf16
> >> >> >> >> >> > > > > >>>>>>>>>           adr     r1, .L4
> >> >> >> >> >> > > > > >>>>>>>>>           ldrd    r0, [r1]
> >> >> >> >> >> > > > > >>>>>>>>>           mov     r2, r3  @ __bf16
> >> >> >> >> >> > > > > >>>>>>>>>           mov     ip, r3  @ __bf16
> >> >> >> >> >> > > > > >>>>>>>>>           bfi     r1, r2, #0, #16
> >> >> >> >> >> > > > > >>>>>>>>>           bfi     r0, ip, #0, #16
> >> >> >> >> >> > > > > >>>>>>>>>           bfi     r1, r3, #16, #16
> >> >> >> >> >> > > > > >>>>>>>>>           bfi     r0, r2, #16, #16
> >> >> >> >> >> > > > > >>>>>>>>>           bx      lr
> >> >> >> >> >> > > > > >>>>>>>>>
> >> >> >> >> >> > > > > >>>>>>>>> This seems to happen because vec_init
> pattern in neon.md
> >> >> >> >> >> > > has VDQ
> >> >> >> >> >> > > > > >>>>>> mode
> >> >> >> >> >> > > > > >>>>>>>>> iterator, which doesn't include V4BF. In
> attached patch, I
> >> >> >> >> >> > > changed
> >> >> >> >> >> > > > > >>>>>>>>> mode
> >> >> >> >> >> > > > > >>>>>>>>> to VDQX which seems to work for the
> test-case, and the
> >> >> >> >> >> > > compiler
> >> >> >> >> >> > > > > >>>> now
> >> >> >> >> >> > > > > >>>>>> generates:
> >> >> >> >> >> > > > > >>>>>>>>> f2:
> >> >> >> >> >> > > > > >>>>>>>>>           vdup.16 d16, r0
> >> >> >> >> >> > > > > >>>>>>>>>           vmov    r0, r1, d16  @ v4bf
> >> >> >> >> >> > > > > >>>>>>>>>           bx      lr
> >> >> >> >> >> > > > > >>>>>>>>>
> >> >> >> >> >> > > > > >>>>>>>>> However, the pattern is also gated on
> TARGET_HAVE_MVE
> >> >> >> >> >> > > and I am
> >> >> >> >> >> > > > > >>>>>> not
> >> >> >> >> >> > > > > >>>>>>>>> sure if either VDQ or VDQX are correct
> modes for MVE since
> >> >> >> >> >> > > MVE
> >> >> >> >> >> > > > > >>>> has
> >> >> >> >> >> > > > > >>>>>>>>> only 128-bit vectors ?
> >> >> >> >> >> > > > > >>>>>>>>>
> >> >> >> >> >> > > > > >>>>>>>> I think patterns common to both Neon and
> MVE should be
> >> >> >> >> >> > > moved to
> >> >> >> >> >> > > > > >>>>>>>> vec-common.md, I don't know why such
> patterns were left in
> >> >> >> >> >> > > > > >>>> neon.md.
> >> >> >> >> >> > > > > >>>>>>> Since we end up calling
> neon_expand_vector_init for both
> >> >> >> >> >> > > NEON and
> >> >> >> >> >> > > > > >>>> MVE,
> >> >> >> >> >> > > > > >>>>>>> I am not sure if we should separate the
> pattern ?
> >> >> >> >> >> > > > > >>>>>>> Would it make sense to FAIL if the mode
> size isn't 16 bytes for
> >> >> >> >> >> > > MVE as
> >> >> >> >> >> > > > > >>>>>>> in attached patch so
> >> >> >> >> >> > > > > >>>>>>> it will call neon_expand_vector_init only
> for 128-bit vectors ?
> >> >> >> >> >> > > > > >>>>>>> Altho hard-coding 16 in the pattern doesn't
> seem a good idea to
> >> >> >> >> >> > > me
> >> >> >> >> >> > > > > >>>> either.
> >> >> >> >> >> > > > > >>>>>> ping
> https://gcc.gnu.org/pipermail/gcc-patches/2021-
> >> >> >> >> >> > > June/572342.html
> >> >> >> >> >> > > > > >>>>>> (attaching patch as text).
> >> >> >> >> >> > > > > >>>>>>
> >> >> >> >> >> > > > > >>>>> --- a/gcc/config/arm/neon.md
> >> >> >> >> >> > > > > >>>>> +++ b/gcc/config/arm/neon.md
> >> >> >> >> >> > > > > >>>>> @@ -459,10 +459,12 @@
> >> >> >> >> >> > > > > >>>>>    )
> >> >> >> >> >> > > > > >>>>>
> >> >> >> >> >> > > > > >>>>>    (define_expand "vec_init<mode><V_elem_l>"
> >> >> >> >> >> > > > > >>>>> -  [(match_operand:VDQ 0 "s_register_operand")
> >> >> >> >> >> > > > > >>>>> +  [(match_operand:VDQX 0
> "s_register_operand")
> >> >> >> >> >> > > > > >>>>>       (match_operand 1 "" "")]
> >> >> >> >> >> > > > > >>>>>      "TARGET_NEON || TARGET_HAVE_MVE"
> >> >> >> >> >> > > > > >>>>>    {
> >> >> >> >> >> > > > > >>>>> +  if (TARGET_HAVE_MVE && GET_MODE_SIZE
> (GET_MODE
> >> >> >> >> >> > > > > >>>> (operands[0])) != 16)
> >> >> >> >> >> > > > > >>>>> +    FAIL;
> >> >> >> >> >> > > > > >>>>>      neon_expand_vector_init (operands[0],
> operands[1]);
> >> >> >> >> >> > > > > >>>>>      DONE;
> >> >> >> >> >> > > > > >>>>>    })
> >> >> >> >> >> > > > > >>>>>
> >> >> >> >> >> > > > > >>>>> I think we should move this to vec-common.md
> like Christophe
> >> >> >> >> >> > > said.
> >> >> >> >> >> > > > > >>>>> Perhaps rather than making it FAIL for non-16
> MVE sizes we just
> >> >> >> >> >> > > disable it in
> >> >> >> >> >> > > > > >>>> the expander condition?
> >> >> >> >> >> > > > > >>>>> "TARGET_NEON || (TARGET_HAVE_MVE &&
> GET_MODE_SIZE (<
> >> >> >> >> >> > > > > >>>> VDQ>mode) != 16)"
> >> >> >> >> >> > > > > >>>> Is it OK to use <MODE>mode ? Because using
> <VDQ>mode resulted
> >> >> >> >> >> > > in lot
> >> >> >> >> >> > > > > >>>> of build errors.
> >> >> >> >> >> > > > > >>>> Also, I think the comparison should be
> inverted, ie, GET_MODE_SIZE
> >> >> >> >> >> > > > > >>>> (<MODE>mode) == 16 since
> >> >> >> >> >> > > > > >>>> we want to make the pattern pass if target is
> MVE and vector size is
> >> >> >> >> >> > > 16 bytes ?
> >> >> >> >> >> > > > > >>>> Do these changes in attached patch look OK ?
> >> >> >> >> >> > > > > >>> Yes, you're right.
> >> >> >> >> >> > > > > >>
> >> >> >> >> >> > > > > >> Can't this be ARM_HAVE_<MODE>_ARITH like in most
> expanders in
> >> >> >> >> >> > > vec-common.md?
> >> >> >> >> >> > > > > >>
> >> >> >> >> >> > > > > >> (maybe with a && !TARGET_REALLY_IWMMXT if needed)
> >> >> >> >> >> > > > > > I wonder if this should be ARM_HAVE_<MODE>_LDST
> instead since
> >> >> >> >> >> > > we're
> >> >> >> >> >> > > > > > initializing the vector ?
> >> >> >> >> >> > > > >
> >> >> >> >> >> > > > >
> >> >> >> >> >> > > > > Well, it really depends on which modes you want to
> enable.
> >> >> >> >> >> > > > >
> >> >> >> >> >> > > > >
> >> >> >> >> >> > > > > Looks like your move VDQ -> VDQ adds V4BF, V8BF and
> DI.
> >> >> >> >> >> > > > >
> >> >> >> >> >> > > > > Are they all OK for Neon?
> >> >> >> >> >> > > > >
> >> >> >> >> >> > > > > They are not OK for MVE.
> >> >> >> >> >> > > > >
> >> >> >> >> >> > > > > Ideally you could add testcases to cover to the
> supported and
> >> >> >> >> >> > > > > unsupported modes for both Neon and MVE.\
> >> >> >> >> >> > > > >
> >> >> >> >> >> > > > > Before your patch, the expander is enabled for MVE
> for 64 bit modes
> >> >> >> >> >> > > > > (V8QI, V4HI, V2SI): what happens in this case? Does
> the compiler crash
> >> >> >> >> >> > > > > or is there something else preventing the match?
> >> >> >> >> >> > > > Hi,
> >> >> >> >> >> > > > Apparently there is VALID_MVE_MODE macro, so is it
> better to use:
> >> >> >> >> >> > > > TARGET_NEON || (TARGET_HAVE_MVE &&
> >> >> >> >> >> > > VALID_MVE_MODE(<MODE>mode))
> >> >> >> >> >> > > > as in the attached patch ?
> >> >> >> >> >> >
> >> >> >> >> >> > The change is ok. I would like to see some testcases like
> Christophe suggested, but this patch just moves the expander around rather
> than introducing new functionality.
> >> >> >> >> >> Hi Kyrill,
> >> >> >> >> >> As mentioned in the first email, the patch improves
> code-gen for
> >> >> >> >> >> following test-case:
> >> >> >> >> >>
> >> >> >> >> >> bfloat16x4_t f (bfloat16_t a)
> >> >> >> >> >> {
> >> >> >> >> >>   return (bfloat16x4_t) {a, a, a, a};
> >> >> >> >> >> }
> >> >> >> >> >>
> >> >> >> >> >> Before patch:
> >> >> >> >> >> f:
> >> >> >> >> >>         mov     r3, r0  @ __bf16
> >> >> >> >> >>         adr     r1, .L4
> >> >> >> >> >>         ldrd    r0, [r1]
> >> >> >> >> >>         mov     r2, r3  @ __bf16
> >> >> >> >> >>         mov     ip, r3  @ __bf16
> >> >> >> >> >>         bfi     r1, r2, #0, #16
> >> >> >> >> >>         bfi     r0, ip, #0, #16
> >> >> >> >> >>         bfi     r1, r3, #16, #16
> >> >> >> >> >>         bfi     r0, r2, #16, #16
> >> >> >> >> >>         bx      lr
> >> >> >> >> >>
> >> >> >> >> >> After patch:
> >> >> >> >> >> f:
> >> >> >> >> >>         vdup.16 d16, r0
> >> >> >> >> >>         vmov    r0, r1, d16  @ v4bf
> >> >> >> >> >>         bx      lr
> >> >> >> >> >>
> >> >> >> >> >> because the patch changes mode from VDQ to VDQX to
> accommodate bf modes.
> >> >> >> >> >> I have included the test in the attached patch.
> >> >> >> >> >> I think Christophe's concerns were mainly about the right
> modes
> >> >> >> >> >> getting enabled for MVE.
> >> >> >> >> >> Unfortunately, I am not sure how to test for that because
> the FE
> >> >> >> >> >> catches invalid modes, and we don't
> >> >> >> >> >> end up hitting the pattern.
> >> >> >> >> >>
> >> >> >> >> >
> >> >> >> >> > Hi Prathamesh,
> >> >> >> >> >
> >> >> >> >> > The new testcase fails on arm-linux-gnueabihf:
> >> >> >> >> >  FAIL: gcc.target/arm/simd/pr98435.c (test for excess errors)
> >> >> >> >> > Excess errors:
> >> >> >> >> >
> /aci-gcc-fsf/builds/gcc-fsf-gccsrc/sysroot-arm-none-linux-gnueabihf/usr/include/gnu/stubs.h:7:11:
> fatal error: gnu/stubs-soft.h: No such file or directory
> >> >> >> >> > compilation terminated.
> >> >> >> >> >
> >> >> >> >> > Because you don't check whether  -mfloat-abi=softfp is
> actually supported.
> >> >> >> >> >
> >> >> >> >> > Can you fix that?
> >> >> >> >> Oops, sorry about that.
> >> >> >> >> The attached patch fixes the test by requiring arm_softfloat
> and makes
> >> >> >> >> it UNSUPPORTED on arm-linux-gnueabihf.
> >> >> >> >> Does it look OK ?
> >> >> >> >>
> >> >> >> >
> >> >> >> > I don't think that's right: it would make the test unsupported
> if softfp is not the default even if the toolchain has the needed multilibs.
> >> >> >> > Did you check eg. with arm-eabi and multilibs enabled?
> >> >> >> Ah OK, thanks for pointing it out!
> >> >> >> Does the attached patch look correct ?
> >> >> >>
> >> >> >
> >> >> > I don't think: this would skip the test even if the toolchain has
> multilibs enabled.
> >> >> > Did you check eg. with arm-eabi and multilibs enabled and the
> usual option overrides?
> >> >> It showed 3 PASS with second patch:
> >> >> /* { dg-skip-if "skip test for hard float" { *-*-* } {
> >> >> "-mfloat-abi=hard" } { "" } } */
> >> >>
> >> >> I ran it using make check-gcc RUNTESTFLAGS="simd.exp=pr98435.c"
> >> >> and built the toolchain using:
> >> >> abe.sh --target arm-eabi --build all --set multilib=aprofile
> gcc=gcc.git~master.
> >> >> I suppose that's correct ?
> >> >
> >> >
> >> > I use rmprofile for arm-eabi, but since aprofile also includes both
> hard and soft multilibs, that should be OK.
> >> > However, I meant overriding the flags used for testing. Here is my
> current list:
> >> >
> >> > -mcpu=cortex-a7/-mfloat-abi=soft/-march=armv7ve+simd
> >> > -mcpu=cortex-a7/-mfloat-abi=hard/-march=armv7ve+simd
> >> > -mthumb/-mcpu=cortex-a7/-mfloat-abi=hard/-march=armv7ve+simd
> >> > -mthumb/-mfloat-abi=soft/-march=armv6s-m
> >> > -mthumb/-mfloat-abi=soft/-march=armv7-m
> >> > -mthumb/-mfloat-abi=hard/-march=armv7e-m+fp
> >> > -mthumb/-mfloat-abi=hard/-march=armv7e-m+fp.dp
> >> > -mthumb/-mfloat-abi=hard/-march=armv8-m.main+fp+dsp
> >> > -mthumb/-mfloat-abi=soft/-march=armv8.1-m.main
> >> Ah right, thanks for the list.
> >> So, with these options -mthumb/-mfloat-abi=hard/-march=armv7e-m+fp,
> >> the test used to PASS but with the patch applied, it now appears
> UNSUPPORTED
> >> because it skips the test for -mfloat-abi=hard.
> >
> >
> > Yes, that's what I wrote above.
> >
> >>
> >> So I guess what we want to check is if -mfloat-abi=hard is used, then
> >> the target has multilib support enabled ?
> >> Could you suggest how to check for that with dejagnu ?
> >
> >
> > No, since you want to use floatfp, you want to make sure that floatfp is
> accepted by the toolchain.
> > Looking at target-supports.exp, I'd suggest you try  arm_softfp_ok.
> That worked, thanks!
> It skipped the test on armhf and passed on arm-eabi with multilibs enabled.
> Is this patch OK to commit ?
>
>
LGTM :-)


> Thanks,
> Prathamesh
> >
> > Christophe
> >
> >>
> >> Thanks,
> >> Prathamesh
> >> >
> >> > Christophe
> >> >
> >> >>
> >> >> gcc -v output:
> >> >> Configured with:
> >> >>
> '/home/prathamesh.kulkarni/abe-toolchain-2/snapshots/gcc.git~master/configure'
> >> >> SHELL=/bin/bash
> >> >>
> --with-mpc=/home/prathamesh.kulkarni/abe-toolchain-2/builds/destdir/x86_64-pc-linux-gnu
> >> >>
> --with-mpfr=/home/prathamesh.kulkarni/abe-toolchain-2/builds/destdir/x86_64-pc-linux-gnu
> >> >>
> --with-gmp=/home/prathamesh.kulkarni/abe-toolchain-2/builds/destdir/x86_64-pc-linux-gnu
> >> >> --with-gnu-as --with-gnu-ld --disable-libmudflap --enable-lto
> >> >> --enable-shared --without-included-gettext --enable-nls
> >> >> --with-system-zlib --disable-sjlj-exceptions
> >> >> --enable-gnu-unique-object --enable-linker-build-id
> >> >> --disable-libstdcxx-pch --enable-c99 --enable-clocale=gnu
> >> >> --enable-libstdcxx-debug --enable-long-long --with-cloog=no
> >> >> --with-ppl=no --with-isl=no --enable-multilib
> >> >> --with-multilib-list=aprofile --enable-threads=no --disable-multiarch
> >> >>
> --with-sysroot=/home/prathamesh.kulkarni/abe-toolchain-2/builds/destdir/x86_64-pc-linux-gnu/arm-eabi
> >> >> --with-newlib --enable-checking=yes --disable-bootstrap
> >> >> --enable-languages=c,c++,lto
> >> >>
> --prefix=/home/prathamesh.kulkarni/abe-toolchain-2/builds/destdir/x86_64-pc-linux-gnu
> >> >> --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
> >> >> --target=arm-eabi
> >> >>
> >> >> Thanks,
> >> >> Prathamesh
> >> >> >
> >> >> >
> >> >> > Christophe
> >> >> >
> >> >> >> Thanks,
> >> >> >> Prathamesh
> >> >> >> >
> >> >> >> > Christophe
> >> >> >> >
> >> >> >> >>
> >> >> >> >> Thanks,
> >> >> >> >> Prathamesh
> >> >> >> >> >
> >> >> >> >> > Thanks
> >> >> >> >> >
> >> >> >> >> > Christophe
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >>
> >> >> >> >> >> Thanks,
> >> >> >> >> >> Prathamesh
> >> >> >> >> >> > Thanks,
> >> >> >> >> >> > Kyrill
> >> >> >> >> >> >
> >> >> >> >> >> > > ping
> https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574206.html
> >> >> >> >> >> > >
> >> >> >> >> >> > > Thanks,
> >> >> >> >> >> > > Prathamesh
> >> >> >> >> >> > > >
> >> >> >> >> >> > > > Thanks,
> >> >> >> >> >> > > > Prathamesh
> >> >> >> >> >> > > > >
> >> >> >> >> >> > > > >
> >> >> >> >> >> > > > > Thanks,
> >> >> >> >> >> > > > >
> >> >> >> >> >> > > > >
> >> >> >> >> >> > > > > Christophe
> >> >> >> >> >> > > > >
> >> >> >> >> >> > > > >
> >> >> >> >> >> > > > > > Thanks,
> >> >> >> >> >> > > > > > Prathamesh
> >> >> >> >> >> > > > > >>
> >> >> >> >> >> > > > > >> Christophe
> >> >> >> >> >> > > > > >>
> >> >> >> >> >> > > > > >>
> >> >> >> >> >> > > > > >>> Ok.
> >> >> >> >> >> > > > > >>> Thanks,
> >> >> >> >> >> > > > > >>> Kyrill
> >> >> >> >> >> > > > > >>>
> >> >> >> >> >> > > > > >>>
> >> >> >> >> >> > > > > >>>> Thanks,
> >> >> >> >> >> > > > > >>>> Prathamesh
> >> >> >> >> >> > > > > >>>>> Thanks,
> >> >> >> >> >> > > > > >>>>> Kyrill
> >> >> >> >> >> > > > > >>>>>
> >> >> >> >> >> > > > > >>>>>> Thanks,
> >> >> >> >> >> > > > > >>>>>> Prathamesh
> >> >> >> >> >> > > > > >>>>>>> Thanks,
> >> >> >> >> >> > > > > >>>>>>> Prathamesh
> >> >> >> >> >> > > > > >>>>>>>> That being said, I suggest you look at
> other similar patterns in
> >> >> >> >> >> > > > > >>>>>>>> vec-common.md, most of which are gated on
> >> >> >> >> >> > > > > >>>>>>>> ARM_HAVE_<MODE>_ARITH
> >> >> >> >> >> > > > > >>>>>>>> and possibly beware of issues with iwmmxt
> :-)
> >> >> >> >> >> > > > > >>>>>>>>
> >> >> >> >> >> > > > > >>>>>>>> Christophe
> >> >> >> >> >> > > > > >>>>>>>>
> >> >> >> >> >> > > > > >>>>>>>>> Thanks,
> >> >> >> >> >> > > > > >>>>>>>>> Prathamesh
>