From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107777 invoked by alias); 4 Aug 2016 08:35:48 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 107598 invoked by uid 89); 4 Aug 2016 08:35:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=margin, matthewwahabarmcom, matthew.wahab@arm.com, tolerance X-HELO: mail-lf0-f65.google.com Received: from mail-lf0-f65.google.com (HELO mail-lf0-f65.google.com) (209.85.215.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 04 Aug 2016 08:35:37 +0000 Received: by mail-lf0-f65.google.com with SMTP id l69so13940246lfg.1 for ; Thu, 04 Aug 2016 01:35:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fWdyvPNwreiLG7eW15hkw8oS03HB02T0sDuHzinP2Ag=; b=gcpzrzJs8aacF70QLsVSOgtMHF7mmJ5KHo5M2DkrwJ9xGlZW+E6uj7fHS+5E8lUKMM UDBIgWzdpXkb9dVSe62fV2Pi0UI3ksLDkfbSo1hO7mVt+uiOuMA+d7mOD7+0QdRJGF+2 WKKRTO5Sofsy8070tXzYp7D+5jCpWguDbQID5IGHAsct2VLsKSUBnnS2Tbl9rCpkg4dY wyqTBTCOQ+tMv+qkkkHd270OwFgsXmEminibwIqhMyUMDCMi3pe5pFJ857g6TU5rsHJ7 A69opxFgdMwzftrNVh1totksRU/f3QsjTkj/+zsS//6G83bbKuv1JrdbPAYGwywvZvBS sDKQ== X-Gm-Message-State: AEkooutsIyva6oKHcOt57Ms6le5INUjuz9RlRjshkgRbBWqZy+VZdm2D919jqgR9DXlUXkm/bgBPDe6wlSQ6Kw== X-Received: by 10.25.158.143 with SMTP id h137mr23233308lfe.83.1470299733602; Thu, 04 Aug 2016 01:35:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.25.231 with HTTP; Thu, 4 Aug 2016 01:35:32 -0700 (PDT) In-Reply-To: <577A7034.1090709@foss.arm.com> References: <573B28A3.9030603@foss.arm.com> <573B2FC9.5070704@foss.arm.com> <573C4AEA.6010803@foss.arm.com> <577A7034.1090709@foss.arm.com> From: Ramana Radhakrishnan Date: Thu, 04 Aug 2016 08:35:00 -0000 Message-ID: Subject: Re: [PATCH 16/17][ARM] Add tests for VFP FP16 ACLE instrinsics. To: Matthew Wahab Cc: gcc-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg00287.txt.bz2 On Mon, Jul 4, 2016 at 3:18 PM, Matthew Wahab 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 > Matthew Wahab > > * 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. >