| Message ID | 1421162314-25779-4-git-send-email-christophe.lyon@linaro.org |
|---|---|
| State | New |
| Headers | show |
> +#ifndef NO_FLOAT_VARIANT > + VLOAD(vector, buffer, , float, f, 32, 2); > + VLOAD(vector, buffer, q, float, f, 32, 4); > +#endif > .... > +#ifndef NO_FLOAT_VARIANT > + VDUP(vector2, , float, f, 32, 2, -15.5f); > + VDUP(vector2, q, float, f, 32, 4, -14.5f); > +#endif > + > +#ifndef NO_FLOAT_VARIANT > +#define FLOAT_VARIANT(MACRO, VAR) \ > + MACRO(VAR, , float, f, 32, 2); \ > + MACRO(VAR, q, float, f, 32, 4) > +#else > +#define FLOAT_VARIANT(MACRO, VAR) > +#endif Double negative! :-) Probably easier on the reader to avoid it, but your call. > diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vmax.c b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vmax.c > new file mode 100644 > index 0000000..2591b16 > --- /dev/null > +++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vmax.c > @@ -0,0 +1,64 @@ > +#include <arm_neon.h> > +#include "arm-neon-ref.h" > +#include "compute-ref-data.h" > + > +#define INSN_NAME vmax > +#define TEST_MSG "VMAX/VMAXQ" > + > +/* Expected results. */ > +VECT_VAR_DECL(expected,int,8,8) [] = { 0xf3, 0xf3, 0xf3, 0xf3, > + 0xf4, 0xf5, 0xf6, 0xf7 }; > +VECT_VAR_DECL(expected,int,16,4) [] = { 0xfff2, 0xfff2, 0xfff2, 0xfff3 }; > +VECT_VAR_DECL(expected,int,32,2) [] = { 0xfffffff0, 0xfffffff1 }; > +VECT_VAR_DECL(expected,int,64,1) [] = { 0x3333333333333333 }; > +VECT_VAR_DECL(expected,uint,8,8) [] = { 0xf3, 0xf3, 0xf3, 0xf3, > + 0xf4, 0xf5, 0xf6, 0xf7 }; > +VECT_VAR_DECL(expected,uint,16,4) [] = { 0xfff1, 0xfff1, 0xfff2, 0xfff3 }; > +VECT_VAR_DECL(expected,uint,32,2) [] = { 0xfffffff0, 0xfffffff1 }; > +VECT_VAR_DECL(expected,uint,64,1) [] = { 0x3333333333333333 }; > +VECT_VAR_DECL(expected,poly,8,8) [] = { 0x33, 0x33, 0x33, 0x33, > + 0x33, 0x33, 0x33, 0x33 }; > +VECT_VAR_DECL(expected,poly,16,4) [] = { 0x3333, 0x3333, 0x3333, 0x3333 }; > +VECT_VAR_DECL(expected,hfloat,32,2) [] = { 0xc1780000, 0xc1700000 }; > +VECT_VAR_DECL(expected,int,8,16) [] = { 0xf4, 0xf4, 0xf4, 0xf4, > + 0xf4, 0xf5, 0xf6, 0xf7, > + 0xf8, 0xf9, 0xfa, 0xfb, > + 0xfc, 0xfd, 0xfe, 0xff }; > +VECT_VAR_DECL(expected,int,16,8) [] = { 0xfff3, 0xfff3, 0xfff3, 0xfff3, > + 0xfff4, 0xfff5, 0xfff6, 0xfff7 }; > +VECT_VAR_DECL(expected,int,32,4) [] = { 0xfffffff1, 0xfffffff1, > + 0xfffffff2, 0xfffffff3 }; > +VECT_VAR_DECL(expected,int,64,2) [] = { 0x3333333333333333, > + 0x3333333333333333 }; > +VECT_VAR_DECL(expected,uint,8,16) [] = { 0xf9, 0xf9, 0xf9, 0xf9, > + 0xf9, 0xf9, 0xf9, 0xf9, > + 0xf9, 0xf9, 0xfa, 0xfb, > + 0xfc, 0xfd, 0xfe, 0xff }; > +VECT_VAR_DECL(expected,uint,16,8) [] = { 0xfff2, 0xfff2, 0xfff2, 0xfff3, > + 0xfff4, 0xfff5, 0xfff6, 0xfff7 }; > +VECT_VAR_DECL(expected,uint,32,4) [] = { 0xfffffff1, 0xfffffff1, > + 0xfffffff2, 0xfffffff3 }; > +VECT_VAR_DECL(expected,uint,64,2) [] = { 0x3333333333333333, > + 0x3333333333333333 }; > +VECT_VAR_DECL(expected,poly,8,16) [] = { 0x33, 0x33, 0x33, 0x33, > + 0x33, 0x33, 0x33, 0x33, > + 0x33, 0x33, 0x33, 0x33, > + 0x33, 0x33, 0x33, 0x33 }; > +VECT_VAR_DECL(expected,poly,16,8) [] = { 0x3333, 0x3333, 0x3333, 0x3333, > + 0x3333, 0x3333, 0x3333, 0x3333 }; > +VECT_VAR_DECL(expected,hfloat,32,4) [] = { 0xc1680000, 0xc1680000, > + 0xc1600000, 0xc1500000 }; > + > +/* Expected results with special FP values. */ > +VECT_VAR_DECL(expected_nan,hfloat,32,4) [] = { 0x7fc00000, 0x7fc00000, > + 0x7fc00000, 0x7fc00000 }; > +VECT_VAR_DECL(expected_mnan,hfloat,32,4) [] = { 0x7fc00000, 0x7fc00000, > + 0x7fc00000, 0x7fc00000 }; > +VECT_VAR_DECL(expected_inf,hfloat,32,4) [] = { 0x7f800000, 0x7f800000, > + 0x7f800000, 0x7f800000 }; > +VECT_VAR_DECL(expected_minf,hfloat,32,4) [] = { 0x3f800000, 0x3f800000, > + 0x3f800000, 0x3f800000 }; > +VECT_VAR_DECL(expected_zero1,hfloat,32,4) [] = { 0x0, 0x0, 0x0, 0x0 }; > +VECT_VAR_DECL(expected_zero2,hfloat,32,4) [] = { 0x0, 0x0, 0x0, 0x0 }; > + > +#include "binary_op_no64.inc" > diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vmin.c b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vmin.c > new file mode 100644 > index 0000000..2b5e87c > --- /dev/null > +++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vmin.c > @@ -0,0 +1,66 @@ > +#include <arm_neon.h> > +#include "arm-neon-ref.h" > +#include "compute-ref-data.h" > + > +#define INSN_NAME vmin > +#define TEST_MSG "VMIN/VMINQ" > + > +/* Expected results. */ > +VECT_VAR_DECL(expected,int,8,8) [] = { 0xf0, 0xf1, 0xf2, 0xf3, > + 0xf3, 0xf3, 0xf3, 0xf3 }; > +VECT_VAR_DECL(expected,int,16,4) [] = { 0xfff0, 0xfff1, 0xfff2, 0xfff2 }; > +VECT_VAR_DECL(expected,int,32,2) [] = { 0xfffffff0, 0xfffffff0 }; > +VECT_VAR_DECL(expected,int,64,1) [] = { 0x3333333333333333 }; > +VECT_VAR_DECL(expected,uint,8,8) [] = { 0xf0, 0xf1, 0xf2, 0xf3, > + 0xf3, 0xf3, 0xf3, 0xf3 }; > +VECT_VAR_DECL(expected,uint,16,4) [] = { 0xfff0, 0xfff1, 0xfff1, 0xfff1 }; > +VECT_VAR_DECL(expected,uint,32,2) [] = { 0xfffffff0, 0xfffffff0 }; > +VECT_VAR_DECL(expected,uint,64,1) [] = { 0x3333333333333333 }; > +VECT_VAR_DECL(expected,poly,8,8) [] = { 0x33, 0x33, 0x33, 0x33, > + 0x33, 0x33, 0x33, 0x33 }; > +VECT_VAR_DECL(expected,poly,16,4) [] = { 0x3333, 0x3333, 0x3333, 0x3333 }; > +VECT_VAR_DECL(expected,hfloat,32,2) [] = { 0xc1800000, 0xc1780000 }; > +VECT_VAR_DECL(expected,int,8,16) [] = { 0xf0, 0xf1, 0xf2, 0xf3, > + 0xf4, 0xf4, 0xf4, 0xf4, > + 0xf4, 0xf4, 0xf4, 0xf4, > + 0xf4, 0xf4, 0xf4, 0xf4 }; > +VECT_VAR_DECL(expected,int,16,8) [] = { 0xfff0, 0xfff1, 0xfff2, 0xfff3, > + 0xfff3, 0xfff3, 0xfff3, 0xfff3 }; > +VECT_VAR_DECL(expected,int,32,4) [] = { 0xfffffff0, 0xfffffff1, > + 0xfffffff1, 0xfffffff1 }; > +VECT_VAR_DECL(expected,int,64,2) [] = { 0x3333333333333333, > + 0x3333333333333333 }; > +VECT_VAR_DECL(expected,uint,8,16) [] = { 0xf0, 0xf1, 0xf2, 0xf3, > + 0xf4, 0xf5, 0xf6, 0xf7, > + 0xf8, 0xf9, 0xf9, 0xf9, > + 0xf9, 0xf9, 0xf9, 0xf9 }; > +VECT_VAR_DECL(expected,uint,16,8) [] = { 0xfff0, 0xfff1, 0xfff2, 0xfff2, > + 0xfff2, 0xfff2, 0xfff2, 0xfff2 }; > +VECT_VAR_DECL(expected,uint,32,4) [] = { 0xfffffff0, 0xfffffff1, > + 0xfffffff1, 0xfffffff1 }; > +VECT_VAR_DECL(expected,uint,64,2) [] = { 0x3333333333333333, > + 0x3333333333333333 }; > +VECT_VAR_DECL(expected,poly,8,16) [] = { 0x33, 0x33, 0x33, 0x33, > + 0x33, 0x33, 0x33, 0x33, > + 0x33, 0x33, 0x33, 0x33, > + 0x33, 0x33, 0x33, 0x33 }; > +VECT_VAR_DECL(expected,poly,16,8) [] = { 0x3333, 0x3333, 0x3333, 0x3333, > + 0x3333, 0x3333, 0x3333, 0x3333 }; > + > +VECT_VAR_DECL(expected,hfloat,32,4) [] = { 0xc1800000, 0xc1700000, > + 0xc1680000, 0xc1680000 }; > +/* Expected results with special FP values. */ > +VECT_VAR_DECL(expected_nan,hfloat,32,4) [] = { 0x7fc00000, 0x7fc00000, > + 0x7fc00000, 0x7fc00000 }; > +VECT_VAR_DECL(expected_mnan,hfloat,32,4) [] = { 0x7fc00000, 0x7fc00000, > + 0x7fc00000, 0x7fc00000 }; > +VECT_VAR_DECL(expected_inf,hfloat,32,4) [] = { 0x3f800000, 0x3f800000, > + 0x3f800000, 0x3f800000 }; > +VECT_VAR_DECL(expected_minf,hfloat,32,4) [] = { 0xff800000, 0xff800000, > + 0xff800000, 0xff800000 }; > +VECT_VAR_DECL(expected_zero1,hfloat,32,4) [] = { 0x80000000, 0x80000000, > + 0x80000000, 0x80000000 }; > +VECT_VAR_DECL(expected_zero2,hfloat,32,4) [] = { 0x80000000, 0x80000000, > + 0x80000000, 0x80000000 }; > + > +#include "binary_op_no64.inc" vmax and vmin do have v<maxmin>_f64 and v<maxmin>q_f64 variants. Otherwise, they look good to me(but I can't approve it). Tejas.
On 16 January 2015 at 14:56, Tejas Belagod <tejas.belagod@arm.com> wrote: >> +#ifndef NO_FLOAT_VARIANT >> + VLOAD(vector, buffer, , float, f, 32, 2); >> + VLOAD(vector, buffer, q, float, f, 32, 4); >> +#endif >> > .... >> >> +#ifndef NO_FLOAT_VARIANT >> + VDUP(vector2, , float, f, 32, 2, -15.5f); >> + VDUP(vector2, q, float, f, 32, 4, -14.5f); >> +#endif >> + >> +#ifndef NO_FLOAT_VARIANT >> +#define FLOAT_VARIANT(MACRO, VAR) \ >> + MACRO(VAR, , float, f, 32, 2); \ >> + MACRO(VAR, q, float, f, 32, 4) >> +#else >> +#define FLOAT_VARIANT(MACRO, VAR) >> +#endif > > > Double negative! :-) Probably easier on the reader to avoid it, but your > call. Oh yes... I am importing my existing code, so I try to minimize changes. >> diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vmax.c >> b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vmax.c >> new file mode 100644 >> index 0000000..2591b16 >> --- /dev/null >> +++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vmax.c >> @@ -0,0 +1,64 @@ >> +#include <arm_neon.h> >> +#include "arm-neon-ref.h" >> +#include "compute-ref-data.h" >> + >> +#define INSN_NAME vmax >> +#define TEST_MSG "VMAX/VMAXQ" >> + >> +/* Expected results. */ >> +VECT_VAR_DECL(expected,int,8,8) [] = { 0xf3, 0xf3, 0xf3, 0xf3, >> + 0xf4, 0xf5, 0xf6, 0xf7 }; >> +VECT_VAR_DECL(expected,int,16,4) [] = { 0xfff2, 0xfff2, 0xfff2, 0xfff3 }; >> +VECT_VAR_DECL(expected,int,32,2) [] = { 0xfffffff0, 0xfffffff1 }; >> +VECT_VAR_DECL(expected,int,64,1) [] = { 0x3333333333333333 }; >> +VECT_VAR_DECL(expected,uint,8,8) [] = { 0xf3, 0xf3, 0xf3, 0xf3, >> + 0xf4, 0xf5, 0xf6, 0xf7 }; >> +VECT_VAR_DECL(expected,uint,16,4) [] = { 0xfff1, 0xfff1, 0xfff2, 0xfff3 >> }; >> +VECT_VAR_DECL(expected,uint,32,2) [] = { 0xfffffff0, 0xfffffff1 }; >> +VECT_VAR_DECL(expected,uint,64,1) [] = { 0x3333333333333333 }; >> +VECT_VAR_DECL(expected,poly,8,8) [] = { 0x33, 0x33, 0x33, 0x33, >> + 0x33, 0x33, 0x33, 0x33 }; >> +VECT_VAR_DECL(expected,poly,16,4) [] = { 0x3333, 0x3333, 0x3333, 0x3333 >> }; >> +VECT_VAR_DECL(expected,hfloat,32,2) [] = { 0xc1780000, 0xc1700000 }; >> +VECT_VAR_DECL(expected,int,8,16) [] = { 0xf4, 0xf4, 0xf4, 0xf4, >> + 0xf4, 0xf5, 0xf6, 0xf7, >> + 0xf8, 0xf9, 0xfa, 0xfb, >> + 0xfc, 0xfd, 0xfe, 0xff }; >> +VECT_VAR_DECL(expected,int,16,8) [] = { 0xfff3, 0xfff3, 0xfff3, 0xfff3, >> + 0xfff4, 0xfff5, 0xfff6, 0xfff7 }; >> +VECT_VAR_DECL(expected,int,32,4) [] = { 0xfffffff1, 0xfffffff1, >> + 0xfffffff2, 0xfffffff3 }; >> +VECT_VAR_DECL(expected,int,64,2) [] = { 0x3333333333333333, >> + 0x3333333333333333 }; >> +VECT_VAR_DECL(expected,uint,8,16) [] = { 0xf9, 0xf9, 0xf9, 0xf9, >> + 0xf9, 0xf9, 0xf9, 0xf9, >> + 0xf9, 0xf9, 0xfa, 0xfb, >> + 0xfc, 0xfd, 0xfe, 0xff }; >> +VECT_VAR_DECL(expected,uint,16,8) [] = { 0xfff2, 0xfff2, 0xfff2, 0xfff3, >> + 0xfff4, 0xfff5, 0xfff6, 0xfff7 }; >> +VECT_VAR_DECL(expected,uint,32,4) [] = { 0xfffffff1, 0xfffffff1, >> + 0xfffffff2, 0xfffffff3 }; >> +VECT_VAR_DECL(expected,uint,64,2) [] = { 0x3333333333333333, >> + 0x3333333333333333 }; >> +VECT_VAR_DECL(expected,poly,8,16) [] = { 0x33, 0x33, 0x33, 0x33, >> + 0x33, 0x33, 0x33, 0x33, >> + 0x33, 0x33, 0x33, 0x33, >> + 0x33, 0x33, 0x33, 0x33 }; >> +VECT_VAR_DECL(expected,poly,16,8) [] = { 0x3333, 0x3333, 0x3333, 0x3333, >> + 0x3333, 0x3333, 0x3333, 0x3333 }; >> +VECT_VAR_DECL(expected,hfloat,32,4) [] = { 0xc1680000, 0xc1680000, >> + 0xc1600000, 0xc1500000 }; >> + >> +/* Expected results with special FP values. */ >> +VECT_VAR_DECL(expected_nan,hfloat,32,4) [] = { 0x7fc00000, 0x7fc00000, >> + 0x7fc00000, 0x7fc00000 }; >> +VECT_VAR_DECL(expected_mnan,hfloat,32,4) [] = { 0x7fc00000, 0x7fc00000, >> + 0x7fc00000, 0x7fc00000 }; >> +VECT_VAR_DECL(expected_inf,hfloat,32,4) [] = { 0x7f800000, 0x7f800000, >> + 0x7f800000, 0x7f800000 }; >> +VECT_VAR_DECL(expected_minf,hfloat,32,4) [] = { 0x3f800000, 0x3f800000, >> + 0x3f800000, 0x3f800000 }; >> +VECT_VAR_DECL(expected_zero1,hfloat,32,4) [] = { 0x0, 0x0, 0x0, 0x0 }; >> +VECT_VAR_DECL(expected_zero2,hfloat,32,4) [] = { 0x0, 0x0, 0x0, 0x0 }; >> + >> +#include "binary_op_no64.inc" >> diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vmin.c >> b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vmin.c >> new file mode 100644 >> index 0000000..2b5e87c >> --- /dev/null >> +++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vmin.c >> @@ -0,0 +1,66 @@ >> +#include <arm_neon.h> >> +#include "arm-neon-ref.h" >> +#include "compute-ref-data.h" >> + >> +#define INSN_NAME vmin >> +#define TEST_MSG "VMIN/VMINQ" >> + >> +/* Expected results. */ >> +VECT_VAR_DECL(expected,int,8,8) [] = { 0xf0, 0xf1, 0xf2, 0xf3, >> + 0xf3, 0xf3, 0xf3, 0xf3 }; >> +VECT_VAR_DECL(expected,int,16,4) [] = { 0xfff0, 0xfff1, 0xfff2, 0xfff2 }; >> +VECT_VAR_DECL(expected,int,32,2) [] = { 0xfffffff0, 0xfffffff0 }; >> +VECT_VAR_DECL(expected,int,64,1) [] = { 0x3333333333333333 }; >> +VECT_VAR_DECL(expected,uint,8,8) [] = { 0xf0, 0xf1, 0xf2, 0xf3, >> + 0xf3, 0xf3, 0xf3, 0xf3 }; >> +VECT_VAR_DECL(expected,uint,16,4) [] = { 0xfff0, 0xfff1, 0xfff1, 0xfff1 >> }; >> +VECT_VAR_DECL(expected,uint,32,2) [] = { 0xfffffff0, 0xfffffff0 }; >> +VECT_VAR_DECL(expected,uint,64,1) [] = { 0x3333333333333333 }; >> +VECT_VAR_DECL(expected,poly,8,8) [] = { 0x33, 0x33, 0x33, 0x33, >> + 0x33, 0x33, 0x33, 0x33 }; >> +VECT_VAR_DECL(expected,poly,16,4) [] = { 0x3333, 0x3333, 0x3333, 0x3333 >> }; >> +VECT_VAR_DECL(expected,hfloat,32,2) [] = { 0xc1800000, 0xc1780000 }; >> +VECT_VAR_DECL(expected,int,8,16) [] = { 0xf0, 0xf1, 0xf2, 0xf3, >> + 0xf4, 0xf4, 0xf4, 0xf4, >> + 0xf4, 0xf4, 0xf4, 0xf4, >> + 0xf4, 0xf4, 0xf4, 0xf4 }; >> +VECT_VAR_DECL(expected,int,16,8) [] = { 0xfff0, 0xfff1, 0xfff2, 0xfff3, >> + 0xfff3, 0xfff3, 0xfff3, 0xfff3 }; >> +VECT_VAR_DECL(expected,int,32,4) [] = { 0xfffffff0, 0xfffffff1, >> + 0xfffffff1, 0xfffffff1 }; >> +VECT_VAR_DECL(expected,int,64,2) [] = { 0x3333333333333333, >> + 0x3333333333333333 }; >> +VECT_VAR_DECL(expected,uint,8,16) [] = { 0xf0, 0xf1, 0xf2, 0xf3, >> + 0xf4, 0xf5, 0xf6, 0xf7, >> + 0xf8, 0xf9, 0xf9, 0xf9, >> + 0xf9, 0xf9, 0xf9, 0xf9 }; >> +VECT_VAR_DECL(expected,uint,16,8) [] = { 0xfff0, 0xfff1, 0xfff2, 0xfff2, >> + 0xfff2, 0xfff2, 0xfff2, 0xfff2 }; >> +VECT_VAR_DECL(expected,uint,32,4) [] = { 0xfffffff0, 0xfffffff1, >> + 0xfffffff1, 0xfffffff1 }; >> +VECT_VAR_DECL(expected,uint,64,2) [] = { 0x3333333333333333, >> + 0x3333333333333333 }; >> +VECT_VAR_DECL(expected,poly,8,16) [] = { 0x33, 0x33, 0x33, 0x33, >> + 0x33, 0x33, 0x33, 0x33, >> + 0x33, 0x33, 0x33, 0x33, >> + 0x33, 0x33, 0x33, 0x33 }; >> +VECT_VAR_DECL(expected,poly,16,8) [] = { 0x3333, 0x3333, 0x3333, 0x3333, >> + 0x3333, 0x3333, 0x3333, 0x3333 }; >> + >> +VECT_VAR_DECL(expected,hfloat,32,4) [] = { 0xc1800000, 0xc1700000, >> + 0xc1680000, 0xc1680000 }; >> +/* Expected results with special FP values. */ >> +VECT_VAR_DECL(expected_nan,hfloat,32,4) [] = { 0x7fc00000, 0x7fc00000, >> + 0x7fc00000, 0x7fc00000 }; >> +VECT_VAR_DECL(expected_mnan,hfloat,32,4) [] = { 0x7fc00000, 0x7fc00000, >> + 0x7fc00000, 0x7fc00000 }; >> +VECT_VAR_DECL(expected_inf,hfloat,32,4) [] = { 0x3f800000, 0x3f800000, >> + 0x3f800000, 0x3f800000 }; >> +VECT_VAR_DECL(expected_minf,hfloat,32,4) [] = { 0xff800000, 0xff800000, >> + 0xff800000, 0xff800000 }; >> +VECT_VAR_DECL(expected_zero1,hfloat,32,4) [] = { 0x80000000, 0x80000000, >> + 0x80000000, 0x80000000 }; >> +VECT_VAR_DECL(expected_zero2,hfloat,32,4) [] = { 0x80000000, 0x80000000, >> + 0x80000000, 0x80000000 }; >> + >> +#include "binary_op_no64.inc" > > > vmax and vmin do have v<maxmin>_f64 and v<maxmin>q_f64 variants. My existing tests only cover armv7 so far. I do plan to expand them once they are all in GCC. > Otherwise, they look good to me(but I can't approve it). > > Tejas. >
On 16 January 2015 at 16:21, Christophe Lyon <christophe.lyon@linaro.org> wrote: > My existing tests only cover armv7 so far. > I do plan to expand them once they are all in GCC. > >> Otherwise, they look good to me(but I can't approve it). >> >> Tejas. >> OK provided, as per the previous couple, that we don;t regression or introduce new fails on aarch64[_be] or aarch32. /Marcus
On 16 January 2015 at 18:14, Marcus Shawcroft <marcus.shawcroft@gmail.com> wrote: > On 16 January 2015 at 16:21, Christophe Lyon <christophe.lyon@linaro.org> wrote: > >> My existing tests only cover armv7 so far. >> I do plan to expand them once they are all in GCC. >> >>> Otherwise, they look good to me(but I can't approve it). >>> >>> Tejas. >>> > > OK provided, as per the previous couple, that we don;t regression or > introduce new fails on aarch64[_be] or aarch32. This patch shows failures on aarch64 and aarch64_be for vmax and vmin when the input is -NaN. It's a corner case, and my reading of the ARM ARM is that the result should the same as on aarch32. I haven't had time to look at it in more details though. So, not OK? > /Marcus
On 16 January 2015 at 17:52, Christophe Lyon <christophe.lyon@linaro.org> wrote: >> OK provided, as per the previous couple, that we don;t regression or >> introduce new fails on aarch64[_be] or aarch32. > > This patch shows failures on aarch64 and aarch64_be for vmax and vmin > when the input is -NaN. > It's a corner case, and my reading of the ARM ARM is that the result > should the same as on aarch32. > I haven't had time to look at it in more details though. > So, not OK? They should have the same behaviour in aarch32 and aarch64. Did you test on HW or a model? /Marcus
On 19 January 2015 at 14:29, Marcus Shawcroft <marcus.shawcroft@gmail.com> wrote: > On 16 January 2015 at 17:52, Christophe Lyon <christophe.lyon@linaro.org> wrote: > >>> OK provided, as per the previous couple, that we don;t regression or >>> introduce new fails on aarch64[_be] or aarch32. >> >> This patch shows failures on aarch64 and aarch64_be for vmax and vmin >> when the input is -NaN. >> It's a corner case, and my reading of the ARM ARM is that the result >> should the same as on aarch32. >> I haven't had time to look at it in more details though. >> So, not OK? > > They should have the same behaviour in aarch32 and aarch64. Did you > test on HW or a model? > I ran the tests on qemu for aarch32 and aarch64-linux, and on the foundation model for aarch64*-elf. > /Marcus
On 19 January 2015 at 15:43, Christophe Lyon <christophe.lyon@linaro.org> wrote: > On 19 January 2015 at 14:29, Marcus Shawcroft > <marcus.shawcroft@gmail.com> wrote: >> On 16 January 2015 at 17:52, Christophe Lyon <christophe.lyon@linaro.org> wrote: >> >>>> OK provided, as per the previous couple, that we don;t regression or >>>> introduce new fails on aarch64[_be] or aarch32. >>> >>> This patch shows failures on aarch64 and aarch64_be for vmax and vmin >>> when the input is -NaN. >>> It's a corner case, and my reading of the ARM ARM is that the result >>> should the same as on aarch32. >>> I haven't had time to look at it in more details though. >>> So, not OK? >> >> They should have the same behaviour in aarch32 and aarch64. Did you >> test on HW or a model? >> > I ran the tests on qemu for aarch32 and aarch64-linux, and on the > foundation model for aarch64*-elf. Leave this one out until we understand why it fails. /Marcus
On 19 January 2015 at 17:54, Marcus Shawcroft <marcus.shawcroft@gmail.com> wrote: > On 19 January 2015 at 15:43, Christophe Lyon <christophe.lyon@linaro.org> wrote: >> On 19 January 2015 at 14:29, Marcus Shawcroft >> <marcus.shawcroft@gmail.com> wrote: >>> On 16 January 2015 at 17:52, Christophe Lyon <christophe.lyon@linaro.org> wrote: >>> >>>>> OK provided, as per the previous couple, that we don;t regression or >>>>> introduce new fails on aarch64[_be] or aarch32. >>>> >>>> This patch shows failures on aarch64 and aarch64_be for vmax and vmin >>>> when the input is -NaN. >>>> It's a corner case, and my reading of the ARM ARM is that the result >>>> should the same as on aarch32. >>>> I haven't had time to look at it in more details though. >>>> So, not OK? >>> >>> They should have the same behaviour in aarch32 and aarch64. Did you >>> test on HW or a model? >>> >> I ran the tests on qemu for aarch32 and aarch64-linux, and on the >> foundation model for aarch64*-elf. > > Leave this one out until we understand why it fails. /Marcus I've looked at this a bit more. We have fmax v0.4s, v0.4s, v1.4s where v0 is a vector of -NaN (0xffc00000) and v1 is a vector of 1. The output is still -NaN (0xffc00000), while the test expects defaultNaN (0x7fc00000). I have executed the test under GDB on AArch64 HW, and noticed that fpcr was 0. I forced it to have DN==1: set $fpcr=0x1000000 but this didn't change the result. Does setting fpcr.dn under gdb actually work? Christophe.
On 21/01/15 15:07, Christophe Lyon wrote: > On 19 January 2015 at 17:54, Marcus Shawcroft > <marcus.shawcroft@gmail.com> wrote: >> On 19 January 2015 at 15:43, Christophe Lyon <christophe.lyon@linaro.org> wrote: >>> On 19 January 2015 at 14:29, Marcus Shawcroft >>> <marcus.shawcroft@gmail.com> wrote: >>>> On 16 January 2015 at 17:52, Christophe Lyon <christophe.lyon@linaro.org> wrote: >>>> >>>>>> OK provided, as per the previous couple, that we don;t regression or >>>>>> introduce new fails on aarch64[_be] or aarch32. >>>>> >>>>> This patch shows failures on aarch64 and aarch64_be for vmax and vmin >>>>> when the input is -NaN. >>>>> It's a corner case, and my reading of the ARM ARM is that the result >>>>> should the same as on aarch32. >>>>> I haven't had time to look at it in more details though. >>>>> So, not OK? >>>> >>>> They should have the same behaviour in aarch32 and aarch64. Did you >>>> test on HW or a model? >>>> >>> I ran the tests on qemu for aarch32 and aarch64-linux, and on the >>> foundation model for aarch64*-elf. >> >> Leave this one out until we understand why it fails. /Marcus > > I've looked at this a bit more. > We have > fmax v0.4s, v0.4s, v1.4s > where v0 is a vector of -NaN (0xffc00000) and v1 is a vector of 1. > > The output is still -NaN (0xffc00000), while the test expects > defaultNaN (0x7fc00000). > In the AArch32 execution state, Advanced SIMD FP arithmetic always uses the DefaultNaN setting regardless of the DN-bit value in the FPSCR. In AArch64 execution state, result of Advanced SIMD FP arithmetic operations depend on the value of the DN-bit i.e. either propagate the input NaN or generate DefaultNaN depending on the value of DN. If you're running your test in the AArch64 execution state, you'd want to define the DN bit and modify the expected results accordingly or have the test poll at runtime what the DN-bit is set to and check expected results dynamically. I think the test already has expected behaviour for AArch32 execution state by expecting DefaultNaN regardless. > I have executed the test under GDB on AArch64 HW, and noticed that fpcr was 0. > I forced it to have DN==1: > set $fpcr=0x1000000 > but this didn't change the result. > > Does setting fpcr.dn under gdb actually work? > It should. Possibly a bug, patches welcome :-). Tejas.
On 22 January 2015 at 12:19, Tejas Belagod <tejas.belagod@arm.com> wrote: > On 21/01/15 15:07, Christophe Lyon wrote: >> >> On 19 January 2015 at 17:54, Marcus Shawcroft >> <marcus.shawcroft@gmail.com> wrote: >>> >>> On 19 January 2015 at 15:43, Christophe Lyon <christophe.lyon@linaro.org> >>> wrote: >>>> >>>> On 19 January 2015 at 14:29, Marcus Shawcroft >>>> <marcus.shawcroft@gmail.com> wrote: >>>>> >>>>> On 16 January 2015 at 17:52, Christophe Lyon >>>>> <christophe.lyon@linaro.org> wrote: >>>>> >>>>>>> OK provided, as per the previous couple, that we don;t regression or >>>>>>> introduce new fails on aarch64[_be] or aarch32. >>>>>> >>>>>> >>>>>> This patch shows failures on aarch64 and aarch64_be for vmax and vmin >>>>>> when the input is -NaN. >>>>>> It's a corner case, and my reading of the ARM ARM is that the result >>>>>> should the same as on aarch32. >>>>>> I haven't had time to look at it in more details though. >>>>>> So, not OK? >>>>> >>>>> >>>>> They should have the same behaviour in aarch32 and aarch64. Did you >>>>> test on HW or a model? >>>>> >>>> I ran the tests on qemu for aarch32 and aarch64-linux, and on the >>>> foundation model for aarch64*-elf. >>> >>> >>> Leave this one out until we understand why it fails. /Marcus >> >> >> I've looked at this a bit more. >> We have >> fmax v0.4s, v0.4s, v1.4s >> where v0 is a vector of -NaN (0xffc00000) and v1 is a vector of 1. >> >> The output is still -NaN (0xffc00000), while the test expects >> defaultNaN (0x7fc00000). >> > > In the AArch32 execution state, Advanced SIMD FP arithmetic always uses the > DefaultNaN setting regardless of the DN-bit value in the FPSCR. In AArch64 > execution state, result of Advanced SIMD FP arithmetic operations depend on > the value of the DN-bit i.e. either propagate the input NaN or generate > DefaultNaN depending on the value of DN. Maybe I'm using an outdated doc. On page 2282 of ARMv8 ARM rev C, I can see only the latter (no diff between aarch32 and aarch64 in FPProcessNan pseudo-code) > If you're running your test in the AArch64 execution state, you'd want to > define the DN bit and modify the expected results accordingly or have the > test poll at runtime what the DN-bit is set to and check expected results > dynamically. Makes sense, I hadn't noticed the different aarch64 spec here. > I think the test already has expected behaviour for AArch32 execution state > by expecting DefaultNaN regardless. Yes. >> I have executed the test under GDB on AArch64 HW, and noticed that fpcr >> was 0. >> I forced it to have DN==1: >> set $fpcr=0x1000000 >> but this didn't change the result. >> >> Does setting fpcr.dn under gdb actually work? >> > > It should. Possibly a bug, patches welcome :-). > :-)
On 22/01/15 14:28, Christophe Lyon wrote: > On 22 January 2015 at 12:19, Tejas Belagod <tejas.belagod@arm.com> wrote: >> On 21/01/15 15:07, Christophe Lyon wrote: >>> >>> On 19 January 2015 at 17:54, Marcus Shawcroft >>> <marcus.shawcroft@gmail.com> wrote: >>>> >>>> On 19 January 2015 at 15:43, Christophe Lyon <christophe.lyon@linaro.org> >>>> wrote: >>>>> >>>>> On 19 January 2015 at 14:29, Marcus Shawcroft >>>>> <marcus.shawcroft@gmail.com> wrote: >>>>>> >>>>>> On 16 January 2015 at 17:52, Christophe Lyon >>>>>> <christophe.lyon@linaro.org> wrote: >>>>>> >>>>>>>> OK provided, as per the previous couple, that we don;t regression or >>>>>>>> introduce new fails on aarch64[_be] or aarch32. >>>>>>> >>>>>>> >>>>>>> This patch shows failures on aarch64 and aarch64_be for vmax and vmin >>>>>>> when the input is -NaN. >>>>>>> It's a corner case, and my reading of the ARM ARM is that the result >>>>>>> should the same as on aarch32. >>>>>>> I haven't had time to look at it in more details though. >>>>>>> So, not OK? >>>>>> >>>>>> >>>>>> They should have the same behaviour in aarch32 and aarch64. Did you >>>>>> test on HW or a model? >>>>>> >>>>> I ran the tests on qemu for aarch32 and aarch64-linux, and on the >>>>> foundation model for aarch64*-elf. >>>> >>>> >>>> Leave this one out until we understand why it fails. /Marcus >>> >>> >>> I've looked at this a bit more. >>> We have >>> fmax v0.4s, v0.4s, v1.4s >>> where v0 is a vector of -NaN (0xffc00000) and v1 is a vector of 1. >>> >>> The output is still -NaN (0xffc00000), while the test expects >>> defaultNaN (0x7fc00000). >>> >> >> In the AArch32 execution state, Advanced SIMD FP arithmetic always uses the >> DefaultNaN setting regardless of the DN-bit value in the FPSCR. In AArch64 >> execution state, result of Advanced SIMD FP arithmetic operations depend on >> the value of the DN-bit i.e. either propagate the input NaN or generate >> DefaultNaN depending on the value of DN. > > Maybe I'm using an outdated doc. On page 2282 of ARMv8 ARM rev C, I > can see only the latter (no diff between aarch32 and aarch64 in > FPProcessNan pseudo-code) > If you see pg. 4005 in the same doc(rev C), you'll see the FPSCR spec - under DN: "The value of this bit only controls scalar floating-point arithmetic. Advanced SIMD arithmetic always uses the Default NaN setting, regardless of the value of the DN bit." Also on page 3180 for the description of VMAX(vector FP), it says: " * max(+0.0, -0.0) = +0.0 * If any input is a NaN, the corresponding result element is the default NaN. " The pseudocode for FPMax () on pg. 3180 passes StandardFPSCRValue() to FPMax() which is on pg. 2285 // StandardFPSCRValue() // ==================== FPCRType StandardFPSCRValue() return ‘00000’ : FPSCR.AHP : ‘11000000000000000000000000’ Here bit-25(FPSCR.DN) is set to 1. Thanks, Tejas. >> If you're running your test in the AArch64 execution state, you'd want to >> define the DN bit and modify the expected results accordingly or have the >> test poll at runtime what the DN-bit is set to and check expected results >> dynamically. > Makes sense, I hadn't noticed the different aarch64 spec here. > >> I think the test already has expected behaviour for AArch32 execution state >> by expecting DefaultNaN regardless. > Yes. > >>> I have executed the test under GDB on AArch64 HW, and noticed that fpcr >>> was 0. >>> I forced it to have DN==1: >>> set $fpcr=0x1000000 >>> but this didn't change the result. >>> >>> Does setting fpcr.dn under gdb actually work? >>> >> >> It should. Possibly a bug, patches welcome :-). >> > :-) >
On 22 January 2015 at 16:22, Tejas Belagod <tejas.belagod@arm.com> wrote: > On 22/01/15 14:28, Christophe Lyon wrote: >> >> On 22 January 2015 at 12:19, Tejas Belagod <tejas.belagod@arm.com> wrote: >>> >>> On 21/01/15 15:07, Christophe Lyon wrote: >>>> >>>> >>>> On 19 January 2015 at 17:54, Marcus Shawcroft >>>> <marcus.shawcroft@gmail.com> wrote: >>>>> >>>>> >>>>> On 19 January 2015 at 15:43, Christophe Lyon >>>>> <christophe.lyon@linaro.org> >>>>> wrote: >>>>>> >>>>>> >>>>>> On 19 January 2015 at 14:29, Marcus Shawcroft >>>>>> <marcus.shawcroft@gmail.com> wrote: >>>>>>> >>>>>>> >>>>>>> On 16 January 2015 at 17:52, Christophe Lyon >>>>>>> <christophe.lyon@linaro.org> wrote: >>>>>>> >>>>>>>>> OK provided, as per the previous couple, that we don;t regression >>>>>>>>> or >>>>>>>>> introduce new fails on aarch64[_be] or aarch32. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This patch shows failures on aarch64 and aarch64_be for vmax and >>>>>>>> vmin >>>>>>>> when the input is -NaN. >>>>>>>> It's a corner case, and my reading of the ARM ARM is that the result >>>>>>>> should the same as on aarch32. >>>>>>>> I haven't had time to look at it in more details though. >>>>>>>> So, not OK? >>>>>>> >>>>>>> >>>>>>> >>>>>>> They should have the same behaviour in aarch32 and aarch64. Did you >>>>>>> test on HW or a model? >>>>>>> >>>>>> I ran the tests on qemu for aarch32 and aarch64-linux, and on the >>>>>> foundation model for aarch64*-elf. >>>>> >>>>> >>>>> >>>>> Leave this one out until we understand why it fails. /Marcus >>>> >>>> >>>> >>>> I've looked at this a bit more. >>>> We have >>>> fmax v0.4s, v0.4s, v1.4s >>>> where v0 is a vector of -NaN (0xffc00000) and v1 is a vector of 1. >>>> >>>> The output is still -NaN (0xffc00000), while the test expects >>>> defaultNaN (0x7fc00000). >>>> >>> >>> In the AArch32 execution state, Advanced SIMD FP arithmetic always uses >>> the >>> DefaultNaN setting regardless of the DN-bit value in the FPSCR. In >>> AArch64 >>> execution state, result of Advanced SIMD FP arithmetic operations depend >>> on >>> the value of the DN-bit i.e. either propagate the input NaN or generate >>> DefaultNaN depending on the value of DN. >> >> >> Maybe I'm using an outdated doc. On page 2282 of ARMv8 ARM rev C, I >> can see only the latter (no diff between aarch32 and aarch64 in >> FPProcessNan pseudo-code) >> > > If you see pg. 4005 in the same doc(rev C), you'll see the FPSCR spec - > under DN: > > "The value of this bit only controls scalar floating-point arithmetic. > Advanced SIMD arithmetic always uses the Default NaN setting, regardless of > the value of the DN bit." > > Also on page 3180 for the description of VMAX(vector FP), it says: > " > * max(+0.0, -0.0) = +0.0 > * If any input is a NaN, the corresponding result element is the default > NaN. > " > Oops I was looking at FMAX (vector) pg 936. > The pseudocode for FPMax () on pg. 3180 passes StandardFPSCRValue() to > FPMax() which is on pg. 2285 > > // StandardFPSCRValue() > // ==================== > FPCRType StandardFPSCRValue() > return ‘00000’ : FPSCR.AHP : ‘11000000000000000000000000’ > > Here bit-25(FPSCR.DN) is set to 1. > So, we should get defaultNaN too on aarch64, and no need to try to force DN to 1 in gdb? What can be wrong? > Thanks, > Tejas. > > >>> If you're running your test in the AArch64 execution state, you'd want to >>> define the DN bit and modify the expected results accordingly or have the >>> test poll at runtime what the DN-bit is set to and check expected results >>> dynamically. >> >> Makes sense, I hadn't noticed the different aarch64 spec here. >> >>> I think the test already has expected behaviour for AArch32 execution >>> state >>> by expecting DefaultNaN regardless. >> >> Yes. >> >>>> I have executed the test under GDB on AArch64 HW, and noticed that fpcr >>>> was 0. >>>> I forced it to have DN==1: >>>> set $fpcr=0x1000000 >>>> but this didn't change the result. >>>> >>>> Does setting fpcr.dn under gdb actually work? >>>> >>> >>> It should. Possibly a bug, patches welcome :-). >>> >> :-) >> > >
On 22/01/15 21:31, Christophe Lyon wrote: > On 22 January 2015 at 16:22, Tejas Belagod <tejas.belagod@arm.com> wrote: >> On 22/01/15 14:28, Christophe Lyon wrote: >>> >>> On 22 January 2015 at 12:19, Tejas Belagod <tejas.belagod@arm.com> wrote: >>>> >>>> On 21/01/15 15:07, Christophe Lyon wrote: >>>>> >>>>> >>>>> On 19 January 2015 at 17:54, Marcus Shawcroft >>>>> <marcus.shawcroft@gmail.com> wrote: >>>>>> >>>>>> >>>>>> On 19 January 2015 at 15:43, Christophe Lyon >>>>>> <christophe.lyon@linaro.org> >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> On 19 January 2015 at 14:29, Marcus Shawcroft >>>>>>> <marcus.shawcroft@gmail.com> wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 16 January 2015 at 17:52, Christophe Lyon >>>>>>>> <christophe.lyon@linaro.org> wrote: >>>>>>>> >>>>>>>>>> OK provided, as per the previous couple, that we don;t regression >>>>>>>>>> or >>>>>>>>>> introduce new fails on aarch64[_be] or aarch32. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> This patch shows failures on aarch64 and aarch64_be for vmax and >>>>>>>>> vmin >>>>>>>>> when the input is -NaN. >>>>>>>>> It's a corner case, and my reading of the ARM ARM is that the result >>>>>>>>> should the same as on aarch32. >>>>>>>>> I haven't had time to look at it in more details though. >>>>>>>>> So, not OK? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> They should have the same behaviour in aarch32 and aarch64. Did you >>>>>>>> test on HW or a model? >>>>>>>> >>>>>>> I ran the tests on qemu for aarch32 and aarch64-linux, and on the >>>>>>> foundation model for aarch64*-elf. >>>>>> >>>>>> >>>>>> >>>>>> Leave this one out until we understand why it fails. /Marcus >>>>> >>>>> >>>>> >>>>> I've looked at this a bit more. >>>>> We have >>>>> fmax v0.4s, v0.4s, v1.4s >>>>> where v0 is a vector of -NaN (0xffc00000) and v1 is a vector of 1. >>>>> >>>>> The output is still -NaN (0xffc00000), while the test expects >>>>> defaultNaN (0x7fc00000). >>>>> >>>> >>>> In the AArch32 execution state, Advanced SIMD FP arithmetic always uses >>>> the >>>> DefaultNaN setting regardless of the DN-bit value in the FPSCR. In >>>> AArch64 >>>> execution state, result of Advanced SIMD FP arithmetic operations depend >>>> on >>>> the value of the DN-bit i.e. either propagate the input NaN or generate >>>> DefaultNaN depending on the value of DN. >>> >>> >>> Maybe I'm using an outdated doc. On page 2282 of ARMv8 ARM rev C, I >>> can see only the latter (no diff between aarch32 and aarch64 in >>> FPProcessNan pseudo-code) >>> >> >> If you see pg. 4005 in the same doc(rev C), you'll see the FPSCR spec - >> under DN: >> >> "The value of this bit only controls scalar floating-point arithmetic. >> Advanced SIMD arithmetic always uses the Default NaN setting, regardless of >> the value of the DN bit." >> >> Also on page 3180 for the description of VMAX(vector FP), it says: >> " >> * max(+0.0, -0.0) = +0.0 >> * If any input is a NaN, the corresponding result element is the default >> NaN. >> " >> > Oops I was looking at FMAX (vector) pg 936. > >> The pseudocode for FPMax () on pg. 3180 passes StandardFPSCRValue() to >> FPMax() which is on pg. 2285 >> >> // StandardFPSCRValue() >> // ==================== >> FPCRType StandardFPSCRValue() >> return ‘00000’ : FPSCR.AHP : ‘11000000000000000000000000’ >> >> Here bit-25(FPSCR.DN) is set to 1. >> > > So, we should get defaultNaN too on aarch64, and no need to try to > force DN to 1 in gdb? > > What can be wrong? > On pg 3180, I see VMAX(FPSIMD) for A32/T32, not A64. I hope we're reading the same document. Regardless of the page number, if you see the pseudocode for VMAX(FPSIMD) for AArch32, StandardFPSCRValue() (i.e. DN = 1) is passed to FPMax() which means generate DefaultNaN() regardless. OTOH, on pg 936, you have FMAX(vector) for A64 where FPMax() in the pseudocode gets just FPCR. Thanks, Tejas. >> Thanks, >> Tejas. >> >> >>>> If you're running your test in the AArch64 execution state, you'd want to >>>> define the DN bit and modify the expected results accordingly or have the >>>> test poll at runtime what the DN-bit is set to and check expected results >>>> dynamically. >>> >>> Makes sense, I hadn't noticed the different aarch64 spec here. >>> >>>> I think the test already has expected behaviour for AArch32 execution >>>> state >>>> by expecting DefaultNaN regardless. >>> >>> Yes. >>> >>>>> I have executed the test under GDB on AArch64 HW, and noticed that fpcr >>>>> was 0. >>>>> I forced it to have DN==1: >>>>> set $fpcr=0x1000000 >>>>> but this didn't change the result. >>>>> >>>>> Does setting fpcr.dn under gdb actually work? >>>>> >>>> >>>> It should. Possibly a bug, patches welcome :-). >>>> >>> :-) >>> >> >> >
On 23 January 2015 at 11:18, Tejas Belagod <tejas.belagod@arm.com> wrote: > On 22/01/15 21:31, Christophe Lyon wrote: >> >> On 22 January 2015 at 16:22, Tejas Belagod <tejas.belagod@arm.com> wrote: >>> >>> On 22/01/15 14:28, Christophe Lyon wrote: >>>> >>>> >>>> On 22 January 2015 at 12:19, Tejas Belagod <tejas.belagod@arm.com> >>>> wrote: >>>>> >>>>> >>>>> On 21/01/15 15:07, Christophe Lyon wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 19 January 2015 at 17:54, Marcus Shawcroft >>>>>> <marcus.shawcroft@gmail.com> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 19 January 2015 at 15:43, Christophe Lyon >>>>>>> <christophe.lyon@linaro.org> >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 19 January 2015 at 14:29, Marcus Shawcroft >>>>>>>> <marcus.shawcroft@gmail.com> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 16 January 2015 at 17:52, Christophe Lyon >>>>>>>>> <christophe.lyon@linaro.org> wrote: >>>>>>>>> >>>>>>>>>>> OK provided, as per the previous couple, that we don;t regression >>>>>>>>>>> or >>>>>>>>>>> introduce new fails on aarch64[_be] or aarch32. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This patch shows failures on aarch64 and aarch64_be for vmax and >>>>>>>>>> vmin >>>>>>>>>> when the input is -NaN. >>>>>>>>>> It's a corner case, and my reading of the ARM ARM is that the >>>>>>>>>> result >>>>>>>>>> should the same as on aarch32. >>>>>>>>>> I haven't had time to look at it in more details though. >>>>>>>>>> So, not OK? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> They should have the same behaviour in aarch32 and aarch64. Did you >>>>>>>>> test on HW or a model? >>>>>>>>> >>>>>>>> I ran the tests on qemu for aarch32 and aarch64-linux, and on the >>>>>>>> foundation model for aarch64*-elf. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Leave this one out until we understand why it fails. /Marcus >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I've looked at this a bit more. >>>>>> We have >>>>>> fmax v0.4s, v0.4s, v1.4s >>>>>> where v0 is a vector of -NaN (0xffc00000) and v1 is a vector of 1. >>>>>> >>>>>> The output is still -NaN (0xffc00000), while the test expects >>>>>> defaultNaN (0x7fc00000). >>>>>> >>>>> >>>>> In the AArch32 execution state, Advanced SIMD FP arithmetic always uses >>>>> the >>>>> DefaultNaN setting regardless of the DN-bit value in the FPSCR. In >>>>> AArch64 >>>>> execution state, result of Advanced SIMD FP arithmetic operations >>>>> depend >>>>> on >>>>> the value of the DN-bit i.e. either propagate the input NaN or generate >>>>> DefaultNaN depending on the value of DN. >>>> >>>> >>>> >>>> Maybe I'm using an outdated doc. On page 2282 of ARMv8 ARM rev C, I >>>> can see only the latter (no diff between aarch32 and aarch64 in >>>> FPProcessNan pseudo-code) >>>> >>> >>> If you see pg. 4005 in the same doc(rev C), you'll see the FPSCR spec - >>> under DN: >>> >>> "The value of this bit only controls scalar floating-point arithmetic. >>> Advanced SIMD arithmetic always uses the Default NaN setting, regardless >>> of >>> the value of the DN bit." >>> >>> Also on page 3180 for the description of VMAX(vector FP), it says: >>> " >>> * max(+0.0, -0.0) = +0.0 >>> * If any input is a NaN, the corresponding result element is the default >>> NaN. >>> " >>> >> Oops I was looking at FMAX (vector) pg 936. >> >>> The pseudocode for FPMax () on pg. 3180 passes StandardFPSCRValue() to >>> FPMax() which is on pg. 2285 >>> >>> // StandardFPSCRValue() >>> // ==================== >>> FPCRType StandardFPSCRValue() >>> return ‘00000’ : FPSCR.AHP : ‘11000000000000000000000000’ >>> >>> Here bit-25(FPSCR.DN) is set to 1. >>> >> >> So, we should get defaultNaN too on aarch64, and no need to try to >> force DN to 1 in gdb? >> >> What can be wrong? >> > > On pg 3180, I see VMAX(FPSIMD) for A32/T32, not A64. I hope we're reading > the same document. > > Regardless of the page number, if you see the pseudocode for VMAX(FPSIMD) > for AArch32, StandardFPSCRValue() (i.e. DN = 1) is passed to FPMax() which > means generate DefaultNaN() regardless. > > OTOH, on pg 936, you have FMAX(vector) for A64 where FPMax() in the > pseudocode gets just FPCR. > > Ok, that was my initial understanding but our discussion confused me. And that's why I tried to force DN = 1 in gdb before single-stepping over fmax v0.4s, v0.4s, v1.4s but it changed nothing :-( Hence my question about a gdb possible bug or misuse. I'll try modifying the test to have it force DN=1. > Thanks, > Tejas. > > >>> Thanks, >>> Tejas. >>> >>> >>>>> If you're running your test in the AArch64 execution state, you'd want >>>>> to >>>>> define the DN bit and modify the expected results accordingly or have >>>>> the >>>>> test poll at runtime what the DN-bit is set to and check expected >>>>> results >>>>> dynamically. >>>> >>>> >>>> Makes sense, I hadn't noticed the different aarch64 spec here. >>>> >>>>> I think the test already has expected behaviour for AArch32 execution >>>>> state >>>>> by expecting DefaultNaN regardless. >>>> >>>> >>>> Yes. >>>> >>>>>> I have executed the test under GDB on AArch64 HW, and noticed that >>>>>> fpcr >>>>>> was 0. >>>>>> I forced it to have DN==1: >>>>>> set $fpcr=0x1000000 >>>>>> but this didn't change the result. >>>>>> >>>>>> Does setting fpcr.dn under gdb actually work? >>>>>> >>>>> >>>>> It should. Possibly a bug, patches welcome :-). >>>>> >>>> :-) >>>> >>> >>> >> > >
On 23 January 2015 at 12:42, Christophe Lyon <christophe.lyon@linaro.org> wrote: > On 23 January 2015 at 11:18, Tejas Belagod <tejas.belagod@arm.com> wrote: >> On 22/01/15 21:31, Christophe Lyon wrote: >>> >>> On 22 January 2015 at 16:22, Tejas Belagod <tejas.belagod@arm.com> wrote: >>>> >>>> On 22/01/15 14:28, Christophe Lyon wrote: >>>>> >>>>> >>>>> On 22 January 2015 at 12:19, Tejas Belagod <tejas.belagod@arm.com> >>>>> wrote: >>>>>> >>>>>> >>>>>> On 21/01/15 15:07, Christophe Lyon wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 19 January 2015 at 17:54, Marcus Shawcroft >>>>>>> <marcus.shawcroft@gmail.com> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 19 January 2015 at 15:43, Christophe Lyon >>>>>>>> <christophe.lyon@linaro.org> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 19 January 2015 at 14:29, Marcus Shawcroft >>>>>>>>> <marcus.shawcroft@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 16 January 2015 at 17:52, Christophe Lyon >>>>>>>>>> <christophe.lyon@linaro.org> wrote: >>>>>>>>>> >>>>>>>>>>>> OK provided, as per the previous couple, that we don;t regression >>>>>>>>>>>> or >>>>>>>>>>>> introduce new fails on aarch64[_be] or aarch32. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This patch shows failures on aarch64 and aarch64_be for vmax and >>>>>>>>>>> vmin >>>>>>>>>>> when the input is -NaN. >>>>>>>>>>> It's a corner case, and my reading of the ARM ARM is that the >>>>>>>>>>> result >>>>>>>>>>> should the same as on aarch32. >>>>>>>>>>> I haven't had time to look at it in more details though. >>>>>>>>>>> So, not OK? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> They should have the same behaviour in aarch32 and aarch64. Did you >>>>>>>>>> test on HW or a model? >>>>>>>>>> >>>>>>>>> I ran the tests on qemu for aarch32 and aarch64-linux, and on the >>>>>>>>> foundation model for aarch64*-elf. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Leave this one out until we understand why it fails. /Marcus >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I've looked at this a bit more. >>>>>>> We have >>>>>>> fmax v0.4s, v0.4s, v1.4s >>>>>>> where v0 is a vector of -NaN (0xffc00000) and v1 is a vector of 1. >>>>>>> >>>>>>> The output is still -NaN (0xffc00000), while the test expects >>>>>>> defaultNaN (0x7fc00000). >>>>>>> >>>>>> >>>>>> In the AArch32 execution state, Advanced SIMD FP arithmetic always uses >>>>>> the >>>>>> DefaultNaN setting regardless of the DN-bit value in the FPSCR. In >>>>>> AArch64 >>>>>> execution state, result of Advanced SIMD FP arithmetic operations >>>>>> depend >>>>>> on >>>>>> the value of the DN-bit i.e. either propagate the input NaN or generate >>>>>> DefaultNaN depending on the value of DN. >>>>> >>>>> >>>>> >>>>> Maybe I'm using an outdated doc. On page 2282 of ARMv8 ARM rev C, I >>>>> can see only the latter (no diff between aarch32 and aarch64 in >>>>> FPProcessNan pseudo-code) >>>>> >>>> >>>> If you see pg. 4005 in the same doc(rev C), you'll see the FPSCR spec - >>>> under DN: >>>> >>>> "The value of this bit only controls scalar floating-point arithmetic. >>>> Advanced SIMD arithmetic always uses the Default NaN setting, regardless >>>> of >>>> the value of the DN bit." >>>> >>>> Also on page 3180 for the description of VMAX(vector FP), it says: >>>> " >>>> * max(+0.0, -0.0) = +0.0 >>>> * If any input is a NaN, the corresponding result element is the default >>>> NaN. >>>> " >>>> >>> Oops I was looking at FMAX (vector) pg 936. >>> >>>> The pseudocode for FPMax () on pg. 3180 passes StandardFPSCRValue() to >>>> FPMax() which is on pg. 2285 >>>> >>>> // StandardFPSCRValue() >>>> // ==================== >>>> FPCRType StandardFPSCRValue() >>>> return ‘00000’ : FPSCR.AHP : ‘11000000000000000000000000’ >>>> >>>> Here bit-25(FPSCR.DN) is set to 1. >>>> >>> >>> So, we should get defaultNaN too on aarch64, and no need to try to >>> force DN to 1 in gdb? >>> >>> What can be wrong? >>> >> >> On pg 3180, I see VMAX(FPSIMD) for A32/T32, not A64. I hope we're reading >> the same document. >> >> Regardless of the page number, if you see the pseudocode for VMAX(FPSIMD) >> for AArch32, StandardFPSCRValue() (i.e. DN = 1) is passed to FPMax() which >> means generate DefaultNaN() regardless. >> >> OTOH, on pg 936, you have FMAX(vector) for A64 where FPMax() in the >> pseudocode gets just FPCR. >> >> > Ok, that was my initial understanding but our discussion confused me. > > And that's why I tried to force DN = 1 in gdb before single-stepping over > fmax v0.4s, v0.4s, v1.4s > > but it changed nothing :-( > Hence my question about a gdb possible bug or misuse. Hmm... user error, I missed one bit set $fpcr=0x2000000 works under gdb. > I'll try modifying the test to have it force DN=1. > Forcing DN=1 in the test makes it pass. I am going to look at adding that cleanly to my test, and resubmit it. Thanks, and sorry for the noise. >> Thanks, >> Tejas. >> >> >>>> Thanks, >>>> Tejas. >>>> >>>> >>>>>> If you're running your test in the AArch64 execution state, you'd want >>>>>> to >>>>>> define the DN bit and modify the expected results accordingly or have >>>>>> the >>>>>> test poll at runtime what the DN-bit is set to and check expected >>>>>> results >>>>>> dynamically. >>>>> >>>>> >>>>> Makes sense, I hadn't noticed the different aarch64 spec here. >>>>> >>>>>> I think the test already has expected behaviour for AArch32 execution >>>>>> state >>>>>> by expecting DefaultNaN regardless. >>>>> >>>>> >>>>> Yes. >>>>> >>>>>>> I have executed the test under GDB on AArch64 HW, and noticed that >>>>>>> fpcr >>>>>>> was 0. >>>>>>> I forced it to have DN==1: >>>>>>> set $fpcr=0x1000000 >>>>>>> but this didn't change the result. >>>>>>> >>>>>>> Does setting fpcr.dn under gdb actually work? >>>>>>> >>>>>> >>>>>> It should. Possibly a bug, patches welcome :-). >>>>>> >>>>> :-) >>>>> >>>> >>>> >>> >> >>
diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/binary_op_no64.inc b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/binary_op_no64.inc new file mode 100644 index 0000000..36efe3a --- /dev/null +++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/binary_op_no64.inc @@ -0,0 +1,120 @@ +/* Can't use the standard binary_op.inc template because vmax has no + 64 bits variant. */ + +#include <math.h> + +#define FNNAME1(NAME) exec_ ## NAME +#define FNNAME(NAME) FNNAME1(NAME) + +void FNNAME (INSN_NAME) (void) +{ + int i; + + /* Basic test: y=vmax(x,x), then store the result. */ +#define TEST_BINARY_OP1(INSN, Q, T1, T2, W, N) \ + VECT_VAR(vector_res, T1, W, N) = \ + INSN##Q##_##T2##W(VECT_VAR(vector, T1, W, N), \ + VECT_VAR(vector2, T1, W, N)); \ + vst1##Q##_##T2##W(VECT_VAR(result, T1, W, N), VECT_VAR(vector_res, T1, W, N)) + +#define TEST_BINARY_OP(INSN, Q, T1, T2, W, N) \ + TEST_BINARY_OP1(INSN, Q, T1, T2, W, N) \ + + DECL_VARIABLE_ALL_VARIANTS(vector); + DECL_VARIABLE_ALL_VARIANTS(vector2); + DECL_VARIABLE_ALL_VARIANTS(vector_res); + + clean_results (); + + /* Initialize input "vector" from "buffer". */ + TEST_MACRO_ALL_VARIANTS_2_5(VLOAD, vector, buffer); +#ifndef NO_FLOAT_VARIANT + VLOAD(vector, buffer, , float, f, 32, 2); + VLOAD(vector, buffer, q, float, f, 32, 4); +#endif + + /* Choose init value arbitrarily, will be used as comparison value. */ + VDUP(vector2, , int, s, 8, 8, -13); + VDUP(vector2, , int, s, 16, 4, -14); + VDUP(vector2, , int, s, 32, 2, -16); + VDUP(vector2, , uint, u, 8, 8, 0xf3); + VDUP(vector2, , uint, u, 16, 4, 0xfff1); + VDUP(vector2, , uint, u, 32, 2, 0xfffffff0); + VDUP(vector2, q, int, s, 8, 16, -12); + VDUP(vector2, q, int, s, 16, 8, -13); + VDUP(vector2, q, int, s, 32, 4, -15); + VDUP(vector2, q, uint, u, 8, 16, 0xf9); + VDUP(vector2, q, uint, u, 16, 8, 0xfff2); + VDUP(vector2, q, uint, u, 32, 4, 0xfffffff1); +#ifndef NO_FLOAT_VARIANT + VDUP(vector2, , float, f, 32, 2, -15.5f); + VDUP(vector2, q, float, f, 32, 4, -14.5f); +#endif + +#ifndef NO_FLOAT_VARIANT +#define FLOAT_VARIANT(MACRO, VAR) \ + MACRO(VAR, , float, f, 32, 2); \ + MACRO(VAR, q, float, f, 32, 4) +#else +#define FLOAT_VARIANT(MACRO, VAR) +#endif + +#define TEST_MACRO_NO64BIT_VARIANT_1_5(MACRO, VAR) \ + MACRO(VAR, , int, s, 8, 8); \ + MACRO(VAR, , int, s, 16, 4); \ + MACRO(VAR, , int, s, 32, 2); \ + MACRO(VAR, , uint, u, 8, 8); \ + MACRO(VAR, , uint, u, 16, 4); \ + MACRO(VAR, , uint, u, 32, 2); \ + MACRO(VAR, q, int, s, 8, 16); \ + MACRO(VAR, q, int, s, 16, 8); \ + MACRO(VAR, q, int, s, 32, 4); \ + MACRO(VAR, q, uint, u, 8, 16); \ + MACRO(VAR, q, uint, u, 16, 8); \ + MACRO(VAR, q, uint, u, 32, 4); \ + FLOAT_VARIANT(MACRO, VAR) + + /* Apply a binary operator named INSN_NAME. */ + TEST_MACRO_NO64BIT_VARIANT_1_5(TEST_BINARY_OP, INSN_NAME); + + CHECK_RESULTS (TEST_MSG, ""); + +#ifndef NO_FLOAT_VARIANT + /* Extra FP tests with special values (NaN, ....) */ + VDUP(vector, q, float, f, 32, 4, 1.0f); + VDUP(vector2, q, float, f, 32, 4, NAN); + TEST_BINARY_OP(INSN_NAME, q, float, f, 32, 4); + CHECK_FP(TEST_MSG, float, 32, 4, PRIx32, expected_nan, " FP special (NaN)"); + + VDUP(vector, q, float, f, 32, 4, -NAN); + VDUP(vector2, q, float, f, 32, 4, 1.0f); + TEST_BINARY_OP(INSN_NAME, q, float, f, 32, 4); + CHECK_FP(TEST_MSG, float, 32, 4, PRIx32, expected_mnan, " FP special (-NaN)"); + + VDUP(vector, q, float, f, 32, 4, 1.0f); + VDUP(vector2, q, float, f, 32, 4, HUGE_VALF); + TEST_BINARY_OP(INSN_NAME, q, float, f, 32, 4); + CHECK_FP(TEST_MSG, float, 32, 4, PRIx32, expected_inf, " FP special (inf)"); + + VDUP(vector, q, float, f, 32, 4, -HUGE_VALF); + VDUP(vector2, q, float, f, 32, 4, 1.0f); + TEST_BINARY_OP(INSN_NAME, q, float, f, 32, 4); + CHECK_FP(TEST_MSG, float, 32, 4, PRIx32, expected_minf, " FP special (-inf)"); + + VDUP(vector, q, float, f, 32, 4, 0.0f); + VDUP(vector2, q, float, f, 32, 4, -0.0f); + TEST_BINARY_OP(INSN_NAME, q, float, f, 32, 4); + CHECK_FP(TEST_MSG, float, 32, 4, PRIx32, expected_zero1, " FP special (-0.0)"); + + VDUP(vector, q, float, f, 32, 4, -0.0f); + VDUP(vector2, q, float, f, 32, 4, 0.0f); + TEST_BINARY_OP(INSN_NAME, q, float, f, 32, 4); + CHECK_FP(TEST_MSG, float, 32, 4, PRIx32, expected_zero2, " FP special (-0.0)"); +#endif +} + +int main (void) +{ + FNNAME (INSN_NAME) (); + return 0; +} diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vhadd.c b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vhadd.c new file mode 100644 index 0000000..0c67df9 --- /dev/null +++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vhadd.c @@ -0,0 +1,54 @@ +#include <arm_neon.h> +#include "arm-neon-ref.h" +#include "compute-ref-data.h" + +#define INSN_NAME vhadd +#define TEST_MSG "VHADD/VHADDQ" + +#define NO_FLOAT_VARIANT + +/* Expected results. */ +VECT_VAR_DECL(expected,int,8,8) [] = { 0xf1, 0xf2, 0xf2, 0xf3, + 0xf3, 0xf4, 0xf4, 0xf5 }; +VECT_VAR_DECL(expected,int,16,4) [] = { 0xfff1, 0xfff1, 0xfff2, 0xfff2 }; +VECT_VAR_DECL(expected,int,32,2) [] = { 0xfffffff0, 0xfffffff0 }; +VECT_VAR_DECL(expected,int,64,1) [] = { 0x3333333333333333 }; +VECT_VAR_DECL(expected,uint,8,8) [] = { 0xf1, 0xf2, 0xf2, 0xf3, + 0xf3, 0xf4, 0xf4, 0xf5 }; +VECT_VAR_DECL(expected,uint,16,4) [] = { 0xfff0, 0xfff1, 0xfff1, 0xfff2 }; +VECT_VAR_DECL(expected,uint,32,2) [] = { 0xfffffff0, 0xfffffff0 }; +VECT_VAR_DECL(expected,uint,64,1) [] = { 0x3333333333333333 }; +VECT_VAR_DECL(expected,poly,8,8) [] = { 0x33, 0x33, 0x33, 0x33, + 0x33, 0x33, 0x33, 0x33 }; +VECT_VAR_DECL(expected,poly,16,4) [] = { 0x3333, 0x3333, 0x3333, 0x3333 }; +VECT_VAR_DECL(expected,hfloat,32,2) [] = { 0x33333333, 0x33333333 }; +VECT_VAR_DECL(expected,int,8,16) [] = { 0xf2, 0xf2, 0xf3, 0xf3, + 0xf4, 0xf4, 0xf5, 0xf5, + 0xf6, 0xf6, 0xf7, 0xf7, + 0xf8, 0xf8, 0xf9, 0xf9 }; +VECT_VAR_DECL(expected,int,16,8) [] = { 0xfff1, 0xfff2, 0xfff2, 0xfff3, + 0xfff3, 0xfff4, 0xfff4, 0xfff5 }; +VECT_VAR_DECL(expected,int,32,4) [] = { 0xfffffff0, 0xfffffff1, + 0xfffffff1, 0xfffffff2 }; +VECT_VAR_DECL(expected,int,64,2) [] = { 0x3333333333333333, + 0x3333333333333333 }; +VECT_VAR_DECL(expected,uint,8,16) [] = { 0xf4, 0xf5, 0xf5, 0xf6, + 0xf6, 0xf7, 0xf7, 0xf8, + 0xf8, 0xf9, 0xf9, 0xfa, + 0xfa, 0xfb, 0xfb, 0xfc }; +VECT_VAR_DECL(expected,uint,16,8) [] = { 0xfff1, 0xfff1, 0xfff2, 0xfff2, + 0xfff3, 0xfff3, 0xfff4, 0xfff4 }; +VECT_VAR_DECL(expected,uint,32,4) [] = { 0xfffffff0, 0xfffffff1, + 0xfffffff1, 0xfffffff2 }; +VECT_VAR_DECL(expected,uint,64,2) [] = { 0x3333333333333333, + 0x3333333333333333 }; +VECT_VAR_DECL(expected,poly,8,16) [] = { 0x33, 0x33, 0x33, 0x33, + 0x33, 0x33, 0x33, 0x33, + 0x33, 0x33, 0x33, 0x33, + 0x33, 0x33, 0x33, 0x33 }; +VECT_VAR_DECL(expected,poly,16,8) [] = { 0x3333, 0x3333, 0x3333, 0x3333, + 0x3333, 0x3333, 0x3333, 0x3333 }; +VECT_VAR_DECL(expected,hfloat,32,4) [] = { 0x33333333, 0x33333333, + 0x33333333, 0x33333333 }; + +#include "binary_op_no64.inc" diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vhsub.c b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vhsub.c new file mode 100644 index 0000000..2431288 --- /dev/null +++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vhsub.c @@ -0,0 +1,52 @@ +#include <arm_neon.h> +#include "arm-neon-ref.h" +#include "compute-ref-data.h" + +#define INSN_NAME vhsub +#define TEST_MSG "VHSUB/VHSUBQ" + +#define NO_FLOAT_VARIANT + +/* Expected results. */ +VECT_VAR_DECL(expected,int,8,8) [] = { 0xfe, 0xff, 0xff, 0x0, + 0x0, 0x1, 0x1, 0x2 }; +VECT_VAR_DECL(expected,int,16,4) [] = { 0xffff, 0xffff, 0x0, 0x0 }; +VECT_VAR_DECL(expected,int,32,2) [] = { 0x0, 0x0 }; +VECT_VAR_DECL(expected,int,64,1) [] = { 0x3333333333333333 }; +VECT_VAR_DECL(expected,uint,8,8) [] = { 0xfe, 0xff, 0xff, 0x0, + 0x0, 0x1, 0x1, 0x2 }; +VECT_VAR_DECL(expected,uint,16,4) [] = { 0xffff, 0x0, 0x0, 0x1 }; +VECT_VAR_DECL(expected,uint,32,2) [] = { 0x0, 0x0 }; +VECT_VAR_DECL(expected,uint,64,1) [] = { 0x3333333333333333 }; +VECT_VAR_DECL(expected,poly,8,8) [] = { 0x33, 0x33, 0x33, 0x33, + 0x33, 0x33, 0x33, 0x33 }; +VECT_VAR_DECL(expected,poly,16,4) [] = { 0x3333, 0x3333, 0x3333, 0x3333 }; +VECT_VAR_DECL(expected,hfloat,32,2) [] = { 0x33333333, 0x33333333 }; +VECT_VAR_DECL(expected,int,8,16) [] = { 0xfe, 0xfe, 0xff, 0xff, + 0x0, 0x0, 0x1, 0x1, + 0x2, 0x2, 0x3, 0x3, + 0x4, 0x4, 0x5, 0x5 }; +VECT_VAR_DECL(expected,int,16,8) [] = { 0xfffe, 0xffff, 0xffff, 0x0, + 0x0, 0x1, 0x1, 0x2 }; +VECT_VAR_DECL(expected,int,32,4) [] = { 0xffffffff, 0x0, 0x0, 0x1 }; +VECT_VAR_DECL(expected,int,64,2) [] = { 0x3333333333333333, + 0x3333333333333333 }; +VECT_VAR_DECL(expected,uint,8,16) [] = { 0xfb, 0xfc, 0xfc, 0xfd, + 0xfd, 0xfe, 0xfe, 0xff, + 0xff, 0x0, 0x0, 0x1, + 0x1, 0x2, 0x2, 0x3 }; +VECT_VAR_DECL(expected,uint,16,8) [] = { 0xffff, 0xffff, 0x0, 0x0, + 0x1, 0x1, 0x2, 0x2 }; +VECT_VAR_DECL(expected,uint,32,4) [] = { 0xffffffff, 0x0, 0x0, 0x1 }; +VECT_VAR_DECL(expected,uint,64,2) [] = { 0x3333333333333333, + 0x3333333333333333 }; +VECT_VAR_DECL(expected,poly,8,16) [] = { 0x33, 0x33, 0x33, 0x33, + 0x33, 0x33, 0x33, 0x33, + 0x33, 0x33, 0x33, 0x33, + 0x33, 0x33, 0x33, 0x33 }; +VECT_VAR_DECL(expected,poly,16,8) [] = { 0x3333, 0x3333, 0x3333, 0x3333, + 0x3333, 0x3333, 0x3333, 0x3333 }; +VECT_VAR_DECL(expected,hfloat,32,4) [] = { 0x33333333, 0x33333333, + 0x33333333, 0x33333333 }; + +#include "binary_op_no64.inc" diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vmax.c b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vmax.c new file mode 100644 index 0000000..2591b16 --- /dev/null +++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vmax.c @@ -0,0 +1,64 @@ +#include <arm_neon.h> +#include "arm-neon-ref.h" +#include "compute-ref-data.h" + +#define INSN_NAME vmax +#define TEST_MSG "VMAX/VMAXQ" + +/* Expected results. */ +VECT_VAR_DECL(expected,int,8,8) [] = { 0xf3, 0xf3, 0xf3, 0xf3, + 0xf4, 0xf5, 0xf6, 0xf7 }; +VECT_VAR_DECL(expected,int,16,4) [] = { 0xfff2, 0xfff2, 0xfff2, 0xfff3 }; +VECT_VAR_DECL(expected,int,32,2) [] = { 0xfffffff0, 0xfffffff1 }; +VECT_VAR_DECL(expected,int,64,1) [] = { 0x3333333333333333 }; +VECT_VAR_DECL(expected,uint,8,8) [] = { 0xf3, 0xf3, 0xf3, 0xf3, + 0xf4, 0xf5, 0xf6, 0xf7 }; +VECT_VAR_DECL(expected,uint,16,4) [] = { 0xfff1, 0xfff1, 0xfff2, 0xfff3 }; +VECT_VAR_DECL(expected,uint,32,2) [] = { 0xfffffff0, 0xfffffff1 }; +VECT_VAR_DECL(expected,uint,64,1) [] = { 0x3333333333333333 }; +VECT_VAR_DECL(expected,poly,8,8) [] = { 0x33, 0x33, 0x33, 0x33, + 0x33, 0x33, 0x33, 0x33 }; +VECT_VAR_DECL(expected,poly,16,4) [] = { 0x3333, 0x3333, 0x3333, 0x3333 }; +VECT_VAR_DECL(expected,hfloat,32,2) [] = { 0xc1780000, 0xc1700000 }; +VECT_VAR_DECL(expected,int,8,16) [] = { 0xf4, 0xf4, 0xf4, 0xf4, + 0xf4, 0xf5, 0xf6, 0xf7, + 0xf8, 0xf9, 0xfa, 0xfb, + 0xfc, 0xfd, 0xfe, 0xff }; +VECT_VAR_DECL(expected,int,16,8) [] = { 0xfff3, 0xfff3, 0xfff3, 0xfff3, + 0xfff4, 0xfff5, 0xfff6, 0xfff7 }; +VECT_VAR_DECL(expected,int,32,4) [] = { 0xfffffff1, 0xfffffff1, + 0xfffffff2, 0xfffffff3 }; +VECT_VAR_DECL(expected,int,64,2) [] = { 0x3333333333333333, + 0x3333333333333333 }; +VECT_VAR_DECL(expected,uint,8,16) [] = { 0xf9, 0xf9, 0xf9, 0xf9, + 0xf9, 0xf9, 0xf9, 0xf9, + 0xf9, 0xf9, 0xfa, 0xfb, + 0xfc, 0xfd, 0xfe, 0xff }; +VECT_VAR_DECL(expected,uint,16,8) [] = { 0xfff2, 0xfff2, 0xfff2, 0xfff3, + 0xfff4, 0xfff5, 0xfff6, 0xfff7 }; +VECT_VAR_DECL(expected,uint,32,4) [] = { 0xfffffff1, 0xfffffff1, + 0xfffffff2, 0xfffffff3 }; +VECT_VAR_DECL(expected,uint,64,2) [] = { 0x3333333333333333, + 0x3333333333333333 }; +VECT_VAR_DECL(expected,poly,8,16) [] = { 0x33, 0x33, 0x33, 0x33, + 0x33, 0x33, 0x33, 0x33, + 0x33, 0x33, 0x33, 0x33, + 0x33, 0x33, 0x33, 0x33 }; +VECT_VAR_DECL(expected,poly,16,8) [] = { 0x3333, 0x3333, 0x3333, 0x3333, + 0x3333, 0x3333, 0x3333, 0x3333 }; +VECT_VAR_DECL(expected,hfloat,32,4) [] = { 0xc1680000, 0xc1680000, + 0xc1600000, 0xc1500000 }; + +/* Expected results with special FP values. */ +VECT_VAR_DECL(expected_nan,hfloat,32,4) [] = { 0x7fc00000, 0x7fc00000, + 0x7fc00000, 0x7fc00000 }; +VECT_VAR_DECL(expected_mnan,hfloat,32,4) [] = { 0x7fc00000, 0x7fc00000, + 0x7fc00000, 0x7fc00000 }; +VECT_VAR_DECL(expected_inf,hfloat,32,4) [] = { 0x7f800000, 0x7f800000, + 0x7f800000, 0x7f800000 }; +VECT_VAR_DECL(expected_minf,hfloat,32,4) [] = { 0x3f800000, 0x3f800000, + 0x3f800000, 0x3f800000 }; +VECT_VAR_DECL(expected_zero1,hfloat,32,4) [] = { 0x0, 0x0, 0x0, 0x0 }; +VECT_VAR_DECL(expected_zero2,hfloat,32,4) [] = { 0x0, 0x0, 0x0, 0x0 }; + +#include "binary_op_no64.inc" diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vmin.c b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vmin.c new file mode 100644 index 0000000..2b5e87c --- /dev/null +++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vmin.c @@ -0,0 +1,66 @@ +#include <arm_neon.h> +#include "arm-neon-ref.h" +#include "compute-ref-data.h" + +#define INSN_NAME vmin +#define TEST_MSG "VMIN/VMINQ" + +/* Expected results. */ +VECT_VAR_DECL(expected,int,8,8) [] = { 0xf0, 0xf1, 0xf2, 0xf3, + 0xf3, 0xf3, 0xf3, 0xf3 }; +VECT_VAR_DECL(expected,int,16,4) [] = { 0xfff0, 0xfff1, 0xfff2, 0xfff2 }; +VECT_VAR_DECL(expected,int,32,2) [] = { 0xfffffff0, 0xfffffff0 }; +VECT_VAR_DECL(expected,int,64,1) [] = { 0x3333333333333333 }; +VECT_VAR_DECL(expected,uint,8,8) [] = { 0xf0, 0xf1, 0xf2, 0xf3, + 0xf3, 0xf3, 0xf3, 0xf3 }; +VECT_VAR_DECL(expected,uint,16,4) [] = { 0xfff0, 0xfff1, 0xfff1, 0xfff1 }; +VECT_VAR_DECL(expected,uint,32,2) [] = { 0xfffffff0, 0xfffffff0 }; +VECT_VAR_DECL(expected,uint,64,1) [] = { 0x3333333333333333 }; +VECT_VAR_DECL(expected,poly,8,8) [] = { 0x33, 0x33, 0x33, 0x33, + 0x33, 0x33, 0x33, 0x33 }; +VECT_VAR_DECL(expected,poly,16,4) [] = { 0x3333, 0x3333, 0x3333, 0x3333 }; +VECT_VAR_DECL(expected,hfloat,32,2) [] = { 0xc1800000, 0xc1780000 }; +VECT_VAR_DECL(expected,int,8,16) [] = { 0xf0, 0xf1, 0xf2, 0xf3, + 0xf4, 0xf4, 0xf4, 0xf4, + 0xf4, 0xf4, 0xf4, 0xf4, + 0xf4, 0xf4, 0xf4, 0xf4 }; +VECT_VAR_DECL(expected,int,16,8) [] = { 0xfff0, 0xfff1, 0xfff2, 0xfff3, + 0xfff3, 0xfff3, 0xfff3, 0xfff3 }; +VECT_VAR_DECL(expected,int,32,4) [] = { 0xfffffff0, 0xfffffff1, + 0xfffffff1, 0xfffffff1 }; +VECT_VAR_DECL(expected,int,64,2) [] = { 0x3333333333333333, + 0x3333333333333333 }; +VECT_VAR_DECL(expected,uint,8,16) [] = { 0xf0, 0xf1, 0xf2, 0xf3, + 0xf4, 0xf5, 0xf6, 0xf7, + 0xf8, 0xf9, 0xf9, 0xf9, + 0xf9, 0xf9, 0xf9, 0xf9 }; +VECT_VAR_DECL(expected,uint,16,8) [] = { 0xfff0, 0xfff1, 0xfff2, 0xfff2, + 0xfff2, 0xfff2, 0xfff2, 0xfff2 }; +VECT_VAR_DECL(expected,uint,32,4) [] = { 0xfffffff0, 0xfffffff1, + 0xfffffff1, 0xfffffff1 }; +VECT_VAR_DECL(expected,uint,64,2) [] = { 0x3333333333333333, + 0x3333333333333333 }; +VECT_VAR_DECL(expected,poly,8,16) [] = { 0x33, 0x33, 0x33, 0x33, + 0x33, 0x33, 0x33, 0x33, + 0x33, 0x33, 0x33, 0x33, + 0x33, 0x33, 0x33, 0x33 }; +VECT_VAR_DECL(expected,poly,16,8) [] = { 0x3333, 0x3333, 0x3333, 0x3333, + 0x3333, 0x3333, 0x3333, 0x3333 }; + +VECT_VAR_DECL(expected,hfloat,32,4) [] = { 0xc1800000, 0xc1700000, + 0xc1680000, 0xc1680000 }; +/* Expected results with special FP values. */ +VECT_VAR_DECL(expected_nan,hfloat,32,4) [] = { 0x7fc00000, 0x7fc00000, + 0x7fc00000, 0x7fc00000 }; +VECT_VAR_DECL(expected_mnan,hfloat,32,4) [] = { 0x7fc00000, 0x7fc00000, + 0x7fc00000, 0x7fc00000 }; +VECT_VAR_DECL(expected_inf,hfloat,32,4) [] = { 0x3f800000, 0x3f800000, + 0x3f800000, 0x3f800000 }; +VECT_VAR_DECL(expected_minf,hfloat,32,4) [] = { 0xff800000, 0xff800000, + 0xff800000, 0xff800000 }; +VECT_VAR_DECL(expected_zero1,hfloat,32,4) [] = { 0x80000000, 0x80000000, + 0x80000000, 0x80000000 }; +VECT_VAR_DECL(expected_zero2,hfloat,32,4) [] = { 0x80000000, 0x80000000, + 0x80000000, 0x80000000 }; + +#include "binary_op_no64.inc" diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vrhadd.c b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vrhadd.c new file mode 100644 index 0000000..8629beb --- /dev/null +++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vrhadd.c @@ -0,0 +1,54 @@ +#include <arm_neon.h> +#include "arm-neon-ref.h" +#include "compute-ref-data.h" + +#define INSN_NAME vrhadd +#define TEST_MSG "VRHADD/VRHADDQ" + +#define NO_FLOAT_VARIANT + +/* Expected results. */ +VECT_VAR_DECL(expected,int,8,8) [] = { 0xf2, 0xf2, 0xf3, 0xf3, + 0xf4, 0xf4, 0xf5, 0xf5 }; +VECT_VAR_DECL(expected,int,16,4) [] = { 0xfff1, 0xfff2, 0xfff2, 0xfff3 }; +VECT_VAR_DECL(expected,int,32,2) [] = { 0xfffffff0, 0xfffffff1 }; +VECT_VAR_DECL(expected,int,64,1) [] = { 0x3333333333333333 }; +VECT_VAR_DECL(expected,uint,8,8) [] = { 0xf2, 0xf2, 0xf3, 0xf3, + 0xf4, 0xf4, 0xf5, 0xf5 }; +VECT_VAR_DECL(expected,uint,16,4) [] = { 0xfff1, 0xfff1, 0xfff2, 0xfff2 }; +VECT_VAR_DECL(expected,uint,32,2) [] = { 0xfffffff0, 0xfffffff1 }; +VECT_VAR_DECL(expected,uint,64,1) [] = { 0x3333333333333333 }; +VECT_VAR_DECL(expected,poly,8,8) [] = { 0x33, 0x33, 0x33, 0x33, + 0x33, 0x33, 0x33, 0x33 }; +VECT_VAR_DECL(expected,poly,16,4) [] = { 0x3333, 0x3333, 0x3333, 0x3333 }; +VECT_VAR_DECL(expected,hfloat,32,2) [] = { 0x33333333, 0x33333333 }; +VECT_VAR_DECL(expected,int,8,16) [] = { 0xf2, 0xf3, 0xf3, 0xf4, + 0xf4, 0xf5, 0xf5, 0xf6, + 0xf6, 0xf7, 0xf7, 0xf8, + 0xf8, 0xf9, 0xf9, 0xfa }; +VECT_VAR_DECL(expected,int,16,8) [] = { 0xfff2, 0xfff2, 0xfff3, 0xfff3, + 0xfff4, 0xfff4, 0xfff5, 0xfff5 }; +VECT_VAR_DECL(expected,int,32,4) [] = { 0xfffffff1, 0xfffffff1, + 0xfffffff2, 0xfffffff2 }; +VECT_VAR_DECL(expected,int,64,2) [] = { 0x3333333333333333, + 0x3333333333333333 }; +VECT_VAR_DECL(expected,uint,8,16) [] = { 0xf5, 0xf5, 0xf6, 0xf6, + 0xf7, 0xf7, 0xf8, 0xf8, + 0xf9, 0xf9, 0xfa, 0xfa, + 0xfb, 0xfb, 0xfc, 0xfc }; +VECT_VAR_DECL(expected,uint,16,8) [] = { 0xfff1, 0xfff2, 0xfff2, 0xfff3, + 0xfff3, 0xfff4, 0xfff4, 0xfff5 }; +VECT_VAR_DECL(expected,uint,32,4) [] = { 0xfffffff1, 0xfffffff1, + 0xfffffff2, 0xfffffff2 }; +VECT_VAR_DECL(expected,uint,64,2) [] = { 0x3333333333333333, + 0x3333333333333333 }; +VECT_VAR_DECL(expected,poly,8,16) [] = { 0x33, 0x33, 0x33, 0x33, + 0x33, 0x33, 0x33, 0x33, + 0x33, 0x33, 0x33, 0x33, + 0x33, 0x33, 0x33, 0x33 }; +VECT_VAR_DECL(expected,poly,16,8) [] = { 0x3333, 0x3333, 0x3333, 0x3333, + 0x3333, 0x3333, 0x3333, 0x3333 }; +VECT_VAR_DECL(expected,hfloat,32,4) [] = { 0x33333333, 0x33333333, + 0x33333333, 0x33333333 }; + +#include "binary_op_no64.inc"