From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89427 invoked by alias); 7 Jul 2015 16:52:39 -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 89411 invoked by uid 89); 7 Jul 2015 16:52:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: eu-smtp-delivery-143.mimecast.com Received: from eu-smtp-delivery-143.mimecast.com (HELO eu-smtp-delivery-143.mimecast.com) (207.82.80.143) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 07 Jul 2015 16:52:37 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-6-9wxen4wXRY2fZgOphwxAHw-1; Tue, 07 Jul 2015 17:52:32 +0100 Received: from [10.2.207.50] ([10.1.2.79]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2015 17:52:31 +0100 Message-ID: <559C03D0.8010104@arm.com> Date: Tue, 07 Jul 2015 16:52:00 -0000 From: Kyrill Tkachov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Alan Lawrence CC: "gcc-patches@gcc.gnu.org" , Ramana Radhakrishnan , Tejas Belagod , Richard Earnshaw Subject: Re: [PATCH 3/16][ARM] Add float16x4_t intrinsics References: <559BC75A.1080606@arm.com> <559BCF8A.4090704@arm.com> <559BFCBD.4080806@arm.com> <559BFF83.20306@arm.com> In-Reply-To: <559BFF83.20306@arm.com> X-MC-Unique: 9wxen4wXRY2fZgOphwxAHw-1 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg00536.txt.bz2 On 07/07/15 17:34, Alan Lawrence wrote: > Kyrill Tkachov wrote: >> On 07/07/15 14:09, Kyrill Tkachov wrote: >>> Hi Alan, >>> >>> On 07/07/15 13:34, Alan Lawrence wrote: >>>> As per https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01335.html >>> For some context, the reference for these is at: >>> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0073a/IHI0073A_arm_= neon_intrinsics_ref.pdf >>> >>> This patch is ok once you and Charles decide on how to proceed with the= two prerequisites. >> On second thought, the ACLE document at http://infocenter.arm.com/help/t= opic/com.arm.doc.ihi0053c/IHI0053C_acle_2_0.pdf >> >> says in 12.2.1: >> "float16 types are only available when the __fp16 type is defined, i.e. = when supported by the hardware" > However, we support __fp16 whenever the user specifies -mfp16-format=3Die= ee or > -mfp16-format=3Dalternative, regardless of whether we have hardware suppo= rt or not. > > (Without hardware support, gcc generates calls to __gnu_f2h_ieee or > __gnu_f2h_alternative instead of vcvtb.f16.f32, and __gnu_h2f_ieee or > __gnu_h2f_alternative instead of vcvtb.f32.f16. However, there is no way = to > support __fp16 just using those hardware instructions without caring abou= t which > format is in use.) Hmmm... In my opinion intrinsics should aim to map to instructions rather t= han go away and call library functions, but this is the existing functionality that current users might depend on :( > > Thus we cannot be consistent with both sides of that 'i.e.', unless we al= so > change when __fp16 is available. > >> I notice that the float32x4_t is unconditionally defined in our arm_neon= .h, however. >> I think this is a bug and its definition should be #ifdef'd properly as = well. > Hmmm. Is this becoming a question of, which potentially-existing code do = we want > to break??? CC'ing the ARM maintainers and Tejas for an ACLE perspective. I think that we'd want to gate the definition of __fp16 on hardware availab= ility as well (the -mfpu option) rather than just arm_fp16_format but I'm not sure of the= impact this will have on existing users. Kyrill > > Cheers, Alan