> -----Original Message-----
> From: Richard Sandiford <richard.sandif...@arm.com>
> Sent: 02 October 2020 11:39
> To: Christophe Lyon <christophe.l...@linaro.org>
> Cc: Kyrylo Tkachov <kyrylo.tkac...@arm.com>; Richard Earnshaw
> <richard.earns...@arm.com>; Dennis Zhang <dennis.zh...@arm.com>;
> gcc-patches@gcc.gnu.org; Ramana Radhakrishnan
> <ramana.radhakrish...@arm.com>
> Subject: [PATCH] arm: Make more use of the new mode macros
> 
> Christophe Lyon <christophe.l...@linaro.org> writes:
> > On Tue, 29 Sep 2020 at 12:38, Kyrylo Tkachov <kyrylo.tkac...@arm.com>
> wrote:
> >>
> >>
> >>
> >> > -----Original Message-----
> >> > From: Richard Sandiford <richard.sandif...@arm.com>
> >> > Sent: 29 September 2020 11:27
> >> > To: Kyrylo Tkachov <kyrylo.tkac...@arm.com>
> >> > Cc: gcc-patches@gcc.gnu.org; ni...@redhat.com; Richard Earnshaw
> >> > <richard.earns...@arm.com>; Ramana Radhakrishnan
> >> > <ramana.radhakrish...@arm.com>; Dennis Zhang
> >> > <dennis.zh...@arm.com>
> >> > Subject: Ping: [PATCH] arm: Add new vector mode macros
> >> >
> >> > Ping
> >> >
> >> > Richard Sandiford <richard.sandif...@arm.com> writes:
> >> > > Kyrylo Tkachov <kyrylo.tkac...@arm.com> writes:
> >> > >> This looks like a productive way forward to me.
> >> > >> Okay if the other maintainer don't object by the end of the week.
> >> > >
> >> > > Thanks.  Dennis pointed out off-list that it regressed
> >> > > armv8_2-fp16-arith-2.c, which was expecting FP16 vectorisation
> >> > > to be rejected for -fno-fast-math.  As mentioned above, that shouldn't
> >> > > be necessary given that FP16 arithmetic (unlike FP32 arithmetic) has a
> >> > > flush-to-zero control.
> >> > >
> >> > > This version therefore updates the test to expect the same output
> >> > > as the -ffast-math version.
> >> > >
> >> > > Tested on arm-linux-gnueabi (hopefully for real this time -- I must
> >> > > have messed up the testing last time).  OK for trunk?
> >> > >
> >>
> >> Ok.
> >> Thanks,
> >> Kyrill
> >>
> >
> > Hi Richard,
> >
> > I didn't notice the initial regression you mention above, but after
> 
> (FWIW, the patch wasn't committed in the original form.  Dennis noticed
> the problem when applying it locally.)
> 
> > this commit (r11-3522),
> > I see:
> > FAIL: gcc.target/arm/armv8_2-fp16-arith-2.c scan-assembler-times
> > vabs\\.f16\\ts[0-9]+, s[0-9]+ 2
> > FAIL: gcc.target/arm/armv8_2-fp16-arith-2.c scan-assembler-times
> > vmul\\.f16\\td[0-9]+, d[0-9]+, d[0-9]+ 1
> > FAIL: gcc.target/arm/armv8_2-fp16-arith-2.c scan-assembler-times
> > vmul\\.f16\\tq[0-9]+, q[0-9]+, q[0-9]+ 1
> > FAIL: gcc.target/arm/armv8_2-fp16-arith-2.c scan-assembler-times
> > vmul\\.f16\\ts[0-9]+, s[0-9]+, s[0-9]+ 1
> > FAIL: gcc.target/arm/armv8_2-fp16-arith-2.c scan-assembler-times
> > vsub\\.f16\\td[0-9]+, d[0-9]+, d[0-9]+ 1
> > FAIL: gcc.target/arm/armv8_2-fp16-arith-2.c scan-assembler-times
> > vsub\\.f16\\tq[0-9]+, q[0-9]+, q[0-9]+ 1
> > FAIL: gcc.target/arm/armv8_2-fp16-arith-2.c scan-assembler-times
> > vsub\\.f16\\ts[0-9]+, s[0-9]+, s[0-9]+ 1
> >
> > Looks like we are running validations differently?
> 
> Hmm, seems like these tests are unsupported on an arm-linux-gnueabihf
> bootstrap (even though Advanced SIMD is enabled by default) since the
> tests specifically want to be able to compile softfp code. :-(
> 
> This patch also uses the macros for patterns that are currently specific
> to neon.md.  Tested on arm-linux-gnueabihf (FWIW), arm-eabi with MVE,
> and armeb-eabi with various combinations.  I see the above failures
> are fixed for the latter two.  OK to install?

Ok.
Thanks,
Kyrill

> 
> Richard

Reply via email to