On Mon, Jul 4, 2016 at 3:18 PM, Matthew Wahab <matthew.wa...@foss.arm.com> wrote: > On 18/05/16 11:58, Matthew Wahab wrote: >> On 18/05/16 02:06, Joseph Myers wrote: >>> On Tue, 17 May 2016, Matthew Wahab wrote: >>> >>>> In some tests, there are unavoidable differences in precision when >>>> calculating the actual and the expected results of an FP16 operation. A >>>> new support function CHECK_FP_BIAS is used so that these tests can check >>>> for an acceptable margin of error. In these tests, the tolerance is >>>> given as the absolute integer difference between the bitvectors of the >>>> expected and the actual results. >>> >>> As far as I can see, CHECK_FP_BIAS is only used in the following patch, >>> but there is another bias test in vsqrth_f16_1.c in this patch. >> >> This is my mistake, the CHECK_FP_BIAS is used for the NEON tests and >> should >> have gone into that patch. The VFP test can do a simpler check so doesn't >> need the macro. >> >>> Could you clarify where the "unavoidable differences in precision" come >>> from? Are the results of some of the new instructions not fully >>> specified, >>> only specified within a given precision? (As far as I can tell the >>> existing v8 instructions for reciprocal and reciprocal square root >>> estimates do have fully defined results, despite being loosely described >>> as esimtates.) >> >> The expected results in the new tests are represented as expressions whose >> value is expected to be calculated at compile-time. This makes the tests >> more readable but differences in the precision between the the compiler >> and >> the HW calculations mean that for vrecpe_f16, vrecps_f16, vrsqrts_f16 and >> vsqrth_f16_1.c the expected and actual results are different. >> >> On reflection, it may be better to remove the CHECK_FP_BIAS macro and, for >> the tests that needed it, to drop the compiler calculation and just use >> the >> expected hexadecimal value. >> >> Other tests depending on compiler-time calculations involve relatively >> simple arithmetic operations and it's not clear if they are susceptible to >> the same rounding errors. I have limited knowledge in FP arithmetic though >> so I'll look into this. > > The scalar tests added in this patch and the vector tests added in the > next patch have been reworked to use the exact values for the expected > results rather than compile-time expressions. The CHECK_FP_BIAS macro is > not used and is removed from this patch. > > The intention with these tests and with the vector tests is to check > that the compiler emits code that produces the same results as the > instruction regardless of any optimizations that it may apply. The > expected results for the tests were produced using inline assembler > taking the same inputs as the intrinsics being tested. > > Other changes are to add and use some (limited) templates for scalar > operations and to add progress and error reporting, making the scalar > tests more consistent with those for the vector operations. > > Tested the series for arm-none-linux-gnueabihf with native bootstrap and > make check and for arm-none-eabi and armeb-none-eabi with make check on > an ARMv8.2-A emulator. > > Ok for trunk? > Matthew >
OK, please watch out for any fallout from the autotesters especially with strange multilib combinations. Ramana > testsuite/ > 2016-07-04 Jiong Wang <jiong.w...@arm.com> > Matthew Wahab <matthew.wa...@arm.com> > > * gcc.target/aarch64/advsimd-intrinsics/binary_scalar_op.inc: New. > * gcc.target/aarch64/advsimd-intrinsics/unary_scalar_op.inc: New. > * gcc.target/aarch64/advsimd-intrinsics/ternary_scalar_op.inc: New. > > * gcc.target/aarch64/advsimd-intrinsics/vabsh_f16_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vaddh_f16_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vcvtah_s32_f16_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vcvtah_u32_f16_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vcvth_f16_s32_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vcvth_f16_u32_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vcvth_n_f16_s32_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vcvth_n_f16_u32_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vcvth_n_s32_f16_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vcvth_n_u32_f16_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vcvth_s32_f16_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vcvth_u32_f16_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vcvtmh_s32_f16_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vcvtmh_u32_f16_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vcvtnh_s32_f16_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vcvtnh_u32_f16_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vcvtph_s32_f16_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vcvtph_u32_f16_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vdivh_f16_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vfmah_f16_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vfmsh_f16_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vmaxnmh_f16_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vminnmh_f16_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vmulh_f16_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vnegh_f16_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vrndah_f16_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vrndh_f16_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vrndih_f16_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vrndmh_f16_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vrndnh_f16_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vrndph_f16_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vrndxh_f16_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vsqrth_f16_1.c: New. > * gcc.target/aarch64/advsimd-intrinsics/vsubh_f16_1.c: New. >
