From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 3470D3838CF9; Thu, 15 Dec 2022 20:27:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3470D3838CF9 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 2BFKQ1Ga011282; Thu, 15 Dec 2022 14:26:01 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 2BFKQ0ZE011277; Thu, 15 Dec 2022 14:26:00 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Thu, 15 Dec 2022 14:26:00 -0600 From: Segher Boessenkool To: Jakub Jelinek Cc: Joseph Myers , "Kewen.Lin" , Michael Meissner , gcc-patches@gcc.gnu.org, Peter Bergner , David Edelsohn , Will Schmidt , William Seurer Subject: Re: [PATCH 2/3] Make __float128 use the _Float128 type, PR target/107299 Message-ID: <20221215202600.GX25951@gate.crashing.org> References: <6b7325c6-6416-d64f-89a8-7341aeb8226c@linux.ibm.com> <3cbaa3d2-4327-c62a-2904-eac5ca506d20@linux.ibm.com> <20221215184927.GW25951@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,KAM_NUMSUBJECT,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, Dec 15, 2022 at 07:56:14PM +0100, Jakub Jelinek wrote: > On Thu, Dec 15, 2022 at 12:49:27PM -0600, Segher Boessenkool wrote: > > Certainly. But different types with the same mode having different > > precision is not so very reasonable, and will likely cause other > > problems as well. > > > > We cannot use precision to order modes or types, that is the core > > problem. A conversion from IEEE QP to double-double (or vice versa) is > > neither widening nor narrowing. > > Sure. For optabs, I bet we don't necessarily need to care that much, if > precision is the same, we can ask for widening and narrowing conversion > and expect only one to be implemented or both doing the same thing between > such modes. But when using libcalls, which library function we use is quite > important because not all of them might be actually implemented in the > library (better keep doing what we've done before). I don't think we should name non-widenings widening, or non-narrowings narrowing. We should call conversions conversions. Even if it doesn't cause technical problems the way it is now (of which I am not convinced at all), faulty names like this are mightily confusing. This is a very real *practical* problem :-( Segher