From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id DE7D73853814 for ; Thu, 29 Jul 2021 21:30:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DE7D73853814 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: 0IL9m55EzqVoymtIlfB1PmoCELkjRcWcw4ehVnI7aN/o1Ru1vZFsh1tLogNnj+vo5fPGr/GMQR aj6dhTBuoUEKeDwt3z3uwZ0HxtQT5sHEE1OykaajS0Z2LQBiS+LKV2UzQ5O9UibJhtDX+2dDlv vP3hltWmXSoZQ+ePVJWYAuISZHZH0C/8f5W/7EncLURnMaIS8UW5eZNrF57HXUTczJhSLDtQ/Q XWKC97K4nhFbRpPTJhGqiRi05ma7fsvX0Ef9cjZk3F+zoYg/D4Lxn3FlS4NNuIT1So/L/5nGFK JLo0geUuH5G6832Lve5ZWoji X-IronPort-AV: E=Sophos;i="5.84,279,1620720000"; d="scan'208";a="64085565" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa2.mentor.iphmx.com with ESMTP; 29 Jul 2021 13:30:23 -0800 IronPort-SDR: AuRSUqyjUV6SwUM10FQQVrOXczm4iy87OxxhzpccK3iJohdqm5GGEDIP6GCkOS82OsqIrlM6Kt fj5XruydkLFSYL3LseQX96e4l1CHStqXaptGtzRVUowOBlmX0AFgUfZyc0/VazBnvsXk3OCRKt 0qoDct5Hw0jA68+ecUqNFvAFAdA1HJDw++pvB86vILfGrUHgjW1Vliwty1hDzUPMrnZxob8/KH gBPMF/h+vM3hVSLo7IbLvbcFLwiWDmYiDsu6efY9Z1giWPGQR2K7k386mfmbbgYXx+4vnl5kF0 mDo= Date: Thu, 29 Jul 2021 21:30:17 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Hongtao Liu CC: liuhongt , Subject: Re: [PATCH 02/10] [i386] Enable _Float16 type for TARGET_SSE2 and above. In-Reply-To: Message-ID: References: <20210721074347.7689-1-hongtao.liu@intel.com> <20210721074347.7689-3-hongtao.liu@intel.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-07.mgc.mentorg.com (139.181.222.7) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3119.5 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_SHORT, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2021 21:30:26 -0000 On Thu, 29 Jul 2021, Hongtao Liu via Gcc-patches wrote: > > Rather than using FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16 whenever TARGET_SSE2 > > (i.e. whenever the type is available), it might make more sense to follow > > AArch64 and use it only when the hardware instructions are available. In > > any case, it seems peculiar to use a different threshold in the "fast" > We want to provide some debuggability to the software emulation. > When there's inconsistency between software emulation and hardware > instructions, users can still debug on non-avx512fp16 processor w/ > software emulation and extra option -fexcess-precision=standard, But that's not the purpose of -fexcess-precision=standard. The purpose is only: when the default case is non-conforming, make it conforming instead. The default case is non-conforming only when the back end has insn patterns pretending to be able to do arithmetic on formats it can't actually do arithmetic on - that is, x87 arithmetic where the insn patterns pretend to support SFmode and DFmode arithmetic but actually use XFmode (and the similar issue for older m68k, but that back end doesn't actually have the required support for -fexcess-precision=standard). So -fexcess-precision=standard should not do anything different from -fexcess-precision=fast regarding _Float16. If you want to be able to enable or disable excess precision for _Float16 separately from the underlying hardware support, that might provide a case for supporting extra options, say -fexcess-precision=16 that means follow the semantics of FLT_EVAL_METHOD == 16 (and with an error for that option on architectures where the given FLT_EVAL_METHOD value isn't supported). But that shouldn't be done by making -fexcess-precision=standard do something outside its scope. > Also since TARGET_C_EXCESS_PRECISION is not related to type, for > testcase w/o _Float16 and is supposed to be runned on x86 fpu, if gcc > is built w/ --with-arch=sapphirerapid, it will regress those > testcases. .i.e. gcc.target/i386/excess-precision-*.c, that's why we > can't follow AArch64. Those tests use -mfpmath=387. In the -mfpmath=387 case, it seems reasonable to keep the rule of promoting to long double, regardless of hardware _Float16 support (-msse2 must also be in effect for the type to be supported at all by the back end). It's the -mfpmath=sse case for which I think following AArch64 is appropriate. -- Joseph S. Myers joseph@codesourcery.com