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 E1E6F38319E4; Fri, 16 Dec 2022 17:56:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E1E6F38319E4 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 2BGHtSi0023197; Fri, 16 Dec 2022 11:55:28 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 2BGHtRjF023196; Fri, 16 Dec 2022 11:55:27 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 16 Dec 2022 11:55:27 -0600 From: Segher Boessenkool To: Michael Meissner , Jakub Jelinek , "Kewen.Lin" , gcc-patches@gcc.gnu.org, Peter Bergner , David Edelsohn , Will Schmidt , William Seurer , Joseph Myers Subject: Re: [PATCH 2/3] Make __float128 use the _Float128 type, PR target/107299 Message-ID: <20221216175527.GB25951@gate.crashing.org> References: <6b7325c6-6416-d64f-89a8-7341aeb8226c@linux.ibm.com> <20221215175949.GV25951@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.7 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,KAM_MANYTO,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: Hi! On Thu, Dec 15, 2022 at 07:09:38PM -0500, Michael Meissner wrote: > On Thu, Dec 15, 2022 at 11:59:49AM -0600, Segher Boessenkool wrote: > > On Wed, Dec 14, 2022 at 10:36:03AM +0100, Jakub Jelinek wrote: > > > The hacks with different precisions of powerpc 128-bit floating types are > > > very unfortunate, it is I assume because the middle-end asserted that scalar > > > floating point types with different modes have different precision. > > > > IEEE QP and double-double cannot be ordered, neither represents a subset > > of the other. But the current middle end does require a total ordering > > for all floating point types (that can be converted to each other). > > > > Mike's precision hack was supposed to give us some time until an actual > > fix was made. But no one has worked on that, and there have been > > failures found with the precision hack as well, it worked remarkably > > well but it isn't perfect. > > > > We cannot move forward in a meaningful way until these problems are > > fixed. We can move around like headless chickens some more of course. > > In general I tend to think most of these automatic widenings are > problematical. But there are cases where it makes sense. These things are *not* widening at all, that is the problem. For some values it is lossy, in either direction. > Lets see. On the PowerPC, there is no support for 32-bit decimal arithmetic. > There you definately the compiler to automatically promoto SDmode to DDmode to > do the arithmetic and then possibly convert it back. Similarly for the limited > 16-bit floating point modes, where you have operations to pack and unpack the > object, but you have no arithmetic. And those things *are* widening, non-lossy in all cases. Well-defined etc. > But I would argue that you NEVER want to automatically promoto DFmode to either > KFmode, TFmode, or IFmode, since those modes are (almost) always going to be > slower than doing the emulation. This is particularly true if we only support > a subset of operations, where some things can be done inline, but a lot of > operations would need to be done via emulation (such as on power8 where we > don't have IEEE 128-bit support in hardware). TFmode is either the same actual mode as either KFmode or IFmode, let's reduce confusion by not talking about it at all anymore. The middle end should never convert to another mode without a good reason for it. But OTOH, both IFmode and KFmode can represent all values in DFmode, you just have to be careful about semantics when eventually converting back. > If the machine independent part of the compiler decides oh we can do this > operation because some operations are present (such as move, negate, absolute > value, and compare), then you likely will wind up promoting the 64-bit type(s) > to 128-bit, doing a call to a slower 128-bit function, and then truncating the > value back to 64-bit is faster than calling a 64-bit emulation function. This does not in general have the correct semantics though (without -ffast-math), so the compiler will not do things like it. > While for the PowerPC, we want to control what is the logical wider type for > floating point types, I can imagine we don't want all backends to have to > implment these hooks if they just have the standard 2-3 floating point modes. KFmode is not wider than IFmode. IFmode is not wider than KFmode. KFmode can represent values IFmode cannot. IFmode can represent valuse KFmode cannot. > I purposelly haven't been looking into 16-bit floating point support, but I > have to imagine there you have the problem that there are at least 2-3 > different 16-bit formats roaming around. This is essentially the same issue in > the PowerPC where you have 2 128-bit floating point types, neither of which is > a pure subset of the other. There are at least six 16-bit float formats in actual use. But we care mostly about IEEE binary16 and about bfloat16, each with or without non-normal values (and the encodings for those reused for extra normal numbers, perhaps). > To my way of thinking, it is a many branching tree. On the PowerPC, you want > SDmode to promoto to DDmode, But it is the backend that should be in control there, not generic code. And that is the way things already work! > and possibly to TDmode. And SFmode mode would > promote to DFmode, In general we do not, it would not have the correct semantics. Anyway, to get us back on track a bit: There should not be any non-explicit conversions from KFmode to IFmode or vice versa. Each of those modes can represent values the other can not. There is no ordering between those modes in that sense, we should not pretend there is one. Segher