From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6996 invoked by alias); 3 Aug 2016 11:52:58 -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 6869 invoked by uid 89); 3 Aug 2016 11:52:57 -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=quantities, sk:convert, D*googlemail.com, 20160704 X-HELO: mail-lf0-f47.google.com Received: from mail-lf0-f47.google.com (HELO mail-lf0-f47.google.com) (209.85.215.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 03 Aug 2016 11:52:46 +0000 Received: by mail-lf0-f47.google.com with SMTP id l69so159157113lfg.1 for ; Wed, 03 Aug 2016 04:52:46 -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=w1MoatsL/uOZ/onUem12BpPy0GTXiORNcb/TDToocp4=; b=kmkpZiQGtyejI+sgor9X0jgbAFAwjC7iFGsa3NWE+E/yqlGLoqF3zA7N2bNnuXpyGO 7QHwWZrWdgrO5r5SD1SNGY+TpxjnO7wm2o/oJiI4Mubb4yoYYseB8LFZ2G37BiRE+NGj eiKRdeRXA/vIG7zbcPTARwYUs51lzLv3B2ttH16oVLFH+VjL1Gq76Tk69cqZTv6YIx3H 44SzmktveHRH7TUzf+qKQ58efruu1XfAcanPOTf2koC3g4gWVPj9CITruBwk7Ugd//sx 3xQFyqNxPnTgjuJpWtsx5x+UD6GyiAY/X2VxWQSgNzf4wQSS7kh9MD2YXQi/UvQEarY7 C1xg== X-Gm-Message-State: AEkoouvZziTk8CUkoAKxL9xDd0TeHsWAKwK0ap/AVg3EZbbZ8LM/oPm6MEY2YwviEs9tqdpLK06UvGQa53vhfQ== X-Received: by 10.25.21.32 with SMTP id l32mr22930275lfi.158.1470225162880; Wed, 03 Aug 2016 04:52:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.25.231 with HTTP; Wed, 3 Aug 2016 04:52:42 -0700 (PDT) In-Reply-To: References: <573B28A3.9030603@foss.arm.com> <573B2C4E.4090900@foss.arm.com> <577A6C6F.3080703@foss.arm.com> From: Ramana Radhakrishnan Date: Wed, 03 Aug 2016 11:52:00 -0000 Message-ID: Subject: Re: [PATCH 8/17][ARM] Add VFP FP16 arithmetic instructions. To: Matthew Wahab Cc: gcc-patches , "Joseph S. Myers" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg00168.txt.bz2 On Thu, Jul 28, 2016 at 12:37 PM, Ramana Radhakrishnan wrote: > On Mon, Jul 4, 2016 at 3:02 PM, Matthew Wahab > wrote: >> On 19/05/16 15:54, Matthew Wahab wrote: >>> On 18/05/16 16:20, Joseph Myers wrote: >>>> On Wed, 18 May 2016, Matthew Wahab wrote: >>>> >>>> In short: instructions for direct HFmode arithmetic should be described >>>> with patterns with the standard names. It's the job of the >>>> architecture-independent compiler to ensure that fp16 arithmetic in the >>>> user's source code only generates direct fp16 arithmetic in GIMPLE (and >>>> thus ends up using those patterns) if that is a correct representation of >>>> the source code's semantics according to ACLE. >>>> >>>> The intrinsics you provide can then be written to use direct arithmetic, >>>> and rely on convert_to_real_1 eliminating the promotions, rather than >>>> needing built-in functions at all, just like many arm_neon.h intrinsics >>>> make direct use of GNU C vector arithmetic. >>> >>> I think it's clear that this has exhausted my knowledge of FP semantics. >>> >>> Forcing promotion to single-precision was to settle concerns brought up in >>> internal discussions about __fp16 semantics. I'll see if anybody has any >>> problem with the changes you suggest. >> >> This patch changes the implementation to use the standard names for the >> HFmode arithmetic. Later patches will also be updated to use the >> arithmetic operators where appropriate. >> >> Changes since the last version of this patch: >> - The standard names for plus, minus, mult, div and fma are defined for >> HF mode. >> - The patterns supporting the new ACLE intrinsics vnegh_f16, vaddh_f16, >> vsubh_f16, vmulh_f16 and vdivh_f16 are removed, the arithmetic >> operators will be used instead. >> - The tests are updated to expect f16 instructions rather than the f32 >> instructions that were previously emitted. >> >> 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. > > > All fine except - > > Why can we not extend the and the l in > vfp.md for fp16 and avoid all the unspecs for vcvta and vrnd* > instructions ? > I now feel reasonably convinced that these can go away and be replaced by extending the and l expanders to consider FP16 as well. Given that we are still only in the middle of stage1 - I'm ok for you to apply this as is and then follow-up with a patch that gets rid of the UNSPECs . If this holds for add, sub and other patterns I don't see why it wouldn't hold for all these patterns as well. Joseph, do you have any opinions on whether we should be extending the standard pattern names or not for btrunc, ceil, round, floor, nearbyint, rint, lround, lfloor and lceil optabs for the HFmode quantities ? Thanks, Ramana > Ramana > > > > >> >> Ok for trunk? >> Matthew >> >> 2016-07-04 Matthew Wahab >> >> * config/arm/iterators.md (Code iterators): Fix some white-space >> in the comments. >> (GLTE): New. >> (ABSNEG): New >> (FCVT): Moved from vfp.md. >> (VCVT_HF_US_N): New. >> (VCVT_SI_US_N): New. >> (VCVT_HF_US): New. >> (VCVTH_US): New. >> (FP16_RND): New. >> (absneg_str): New. >> (FCVTI32typename): Moved from vfp.md. >> (sup): Add UNSPEC_VCVTA_S, UNSPEC_VCVTA_U, UNSPEC_VCVTM_S, >> UNSPEC_VCVTM_U, UNSPEC_VCVTN_S, UNSPEC_VCVTN_U, UNSPEC_VCVTP_S, >> UNSPEC_VCVTP_U, UNSPEC_VCVT_HF_S_N, UNSPEC_VCVT_HF_U_N, >> UNSPEC_VCVT_SI_S_N, UNSPEC_VCVT_SI_U_N, UNSPEC_VCVTH_S_N, >> UNSPEC_VCVTH_U_N, UNSPEC_VCVTH_S and UNSPEC_VCVTH_U. >> >> (vcvth_op): New. >> (fp16_rnd_str): New. >> (fp16_rnd_insn): New. > > >> * config/arm/unspecs.md (UNSPEC_VCVT_HF_S_N): New. >> (UNSPEC_VCVT_HF_U_N): New. >> (UNSPEC_VCVT_SI_S_N): New. >> (UNSPEC_VCVT_SI_U_N): New. >> (UNSPEC_VCVTH_S): New. >> (UNSPEC_VCVTH_U): New. >> (UNSPEC_VCVTA_S): New. >> (UNSPEC_VCVTA_U): New. >> (UNSPEC_VCVTM_S): New. >> (UNSPEC_VCVTM_U): New. >> (UNSPEC_VCVTN_S): New. >> (UNSPEC_VCVTN_U): New. >> (UNSPEC_VCVTP_S): New. >> (UNSPEC_VCVTP_U): New. >> (UNSPEC_VCVTP_S): New. >> (UNSPEC_VCVTP_U): New. >> (UNSPEC_VRND): New. >> (UNSPEC_VRNDA): New. >> (UNSPEC_VRNDI): New. >> (UNSPEC_VRNDM): New. >> (UNSPEC_VRNDN): New. >> (UNSPEC_VRNDP): New. >> (UNSPEC_VRNDX): New. >> * config/arm/vfp.md (hf2): New. >> (neon_vabshf): New. >> (neon_vhf): New. >> (neon_vrndihf): New. >> (addhf3): New. >> (subhf3): New. >> (divhf3): New. >> (mulhf3): New. >> (*mulsf3neghf_vfp): New. >> (*negmulhf3_vfp): New. >> (*mulsf3addhf_vfp): New. >> (*mulhf3subhf_vfp): New. >> (*mulhf3neghfaddhf_vfp): New. >> (*mulhf3neghfsubhf_vfp): New. >> (fmahf4): New. >> (neon_vfmahf): New. >> (fmsubhf4_fp16): New. >> (neon_vfmshf): New. >> (*fnmsubhf4): New. >> (*fnmaddhf4): New. >> (neon_vsqrthf): New. >> (neon_vrsqrtshf): New. >> (FCVT): Move to iterators.md. >> (FCVTI32typename): Likewise. >> (neon_vcvthhf): New. >> (neon_vcvthsi): New. >> (neon_vcvth_nhf_unspec): New. >> (neon_vcvth_nhf): New. >> (neon_vcvth_nsi_unspec): New. >> (neon_vcvth_nsi): New. >> (neon_vcvthsi): New. >> (neon_hf): New. >> >> testsuite/ >> 2016-07-04 Matthew Wahab >> >> >> * gcc.target/arm/armv8_2-fp16-arith-1.c: New. >> * gcc.target/arm/armv8_2-fp16-conv-1.c: New. >>