From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10218 invoked by alias); 18 Feb 2015 04:44:09 -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 10206 invoked by uid 89); 18 Feb 2015 04:44:09 -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,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-HELO: mail-ie0-f179.google.com Received: from mail-ie0-f179.google.com (HELO mail-ie0-f179.google.com) (209.85.223.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 18 Feb 2015 04:44:07 +0000 Received: by iecrl12 with SMTP id rl12so43834238iec.2 for ; Tue, 17 Feb 2015 20:44:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=rnroqKDo4vcLqiyQyFBqxIWALN/m5JFrn+F+Otj621o=; b=UW+qwEqm/oTHF4pOH6g1baxNxOyrJEy2ElOafQ7MTxNO38lFH/BRNMPaaPMvHx4RJ3 xJTL2VQ3YElWaRDLTRcrhJKs/Bt9TAEGo4hLC7BP7zvp5gzAngMzmSxFEYFrWVGg8jvD 4+oFhvv90f9+mA06WyXROb62uXRItKGSyNYVHfR3K0AQYZsntHKGsmEfE9yz3SsLG+V2 mWwZLWnKHdi1P39XJLDhWwqVh8VuWgt+QoH8fdG0wr1nL/Rgx8YFSQoROr3Qfz2TN2qJ M7tSmnwy2bvd2jikPvT5LepgTJogLCswb4OObYJLU+59SoU3wmbIkmrW6uolaCu5zIJE SNnQ== X-Gm-Message-State: ALoCoQksRjb5z4d0U4KeYK8MWlZerTVmxQn+cnlkx99/edMtRu0tqG9a2hR3tTkZC1OD/4xPBjvE X-Received: by 10.50.108.108 with SMTP id hj12mr669398igb.47.1424234644978; Tue, 17 Feb 2015 20:44:04 -0800 (PST) Received: from [10.40.41.120] ([96.88.74.93]) by mx.google.com with ESMTPSA id vk4sm11372295igc.11.2015.02.17.20.44.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Feb 2015 20:44:04 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: patch to fix rtl documentation for new floating point comparisons From: Kenneth Zadeck In-Reply-To: Date: Wed, 18 Feb 2015 04:44:00 -0000 Cc: Richard Earnshaw , Paolo Bonzini , gcc-patches Content-Transfer-Encoding: quoted-printable Message-Id: References: <54D9063D.1000102@naturalbridge.com> <54D95C03.1090904@naturalbridge.com> <54DFAF8C.6000906@gnu.org> <54E0C471.1090704@naturalbridge.com> <54E312E4.707@foss.arm.com> <54E3DA03.5010901@naturalbridge.com> To: Joseph Myers X-SW-Source: 2015-02/txt/msg01059.txt.bz2 > On Feb 17, 2015, at 6:01 PM, Joseph Myers wrote: >=20 >> On Tue, 17 Feb 2015, Kenneth Zadeck wrote: >>=20 >>> On 02/17/2015 07:05 AM, Joseph Myers wrote: >>>> On Tue, 17 Feb 2015, Richard Earnshaw wrote: >>>>=20 >>>> So the problem we have today is the compiler has no way to distinguish >>>> between, say, < and __builtin_isless. According to Annex F (c99) the >>>> former should be signalling while the latter quiet. >>> We do have a way: < is LT and __builtin_isless is !UNGE. >>>=20 >>> __builtin_islessgreater is !UNEQ. The question is whether it's also LT= GT >>> or whether LTGT means LT || GT. And the existing documentation of >>> LTGT_EXPR leaves this unspecified, which seems clearly unhelpful. Eith= er >>> way, you have existing code in GCC that's incorrect (i.e. that does not >>> correspond to the set of transformations that are actually valid for the >>> chosen semantics). >> Having spent the majority of my gcc life at the rtl level, i find it >> astonishing that the designers of the tree level allowed this machine >> dependency to get into what i was always told was a pristine machine >> independent pass. i would have thought that the at the tree level this >> could/should be nailed down to being quiet and if someone wanted to supp= ort a >> noisy version in their port, then they would look for lt || gt when conv= erting >> to the rtl level which has never been so pristine. >=20 > As I said in , = I=20 > can't find any posting to gcc-patches of the r82467 commit that introduce= d=20 > the "possible exception" wording. >=20 >> it would be nice to know exactly how many ports (if any) actually have a= noisy >> version of this in hardware. ltgt is not a common primitive (it is not e= ven >> mentioned in the ieee fp standards). >=20 > For example, on MIPS the C.cond.fmt instruction has a four-bit condition= =20 > field: "In the cond field of the instruction: cond 2..1 specify the natur= e=20 > of the comparison (equals, less than, and so on); cond 0 specifies whethe= r=20 > the comparison is ordered or unordered, i.e. false or true if any operand= =20 > is a NaN; cond 3 indicates whether the instruction should signal an=20 > exception on QNaN inputs, or not". Together with possibly negating the=20 > result you get all 32 possible comparisons (choice of whether the=20 > comparison is true or false for each of =3D < > unordered, choice of whet= her=20 > to raise invalid for quiet NaNs). >=20 This is a pretty weak motivation. Computer architects love this kind of = thing, assuming they have the opcode space. Just give them every possible= combination and let the programmers decide what is useful - and by doing = that, the architect saves a couple of muxes and gate delays. But that do= esn't mean that the layers of software need to support all of this, Espec= ially , in this case when there is not motivation from either the fp stand= ards or the language standards. >>> I think the main difficulty in proper Annex F support would be making >>> optimizers (on each IR) understand the side-effects operations have in >>> terms of raising exceptions, and how operations may take the rounding m= ode >>> or existing exceptions raised as inputs - with an associated issue of >>> defining the existing default floating-point rules well enough to keep a >>> default mode that doesn't unduly inhibit optimization. >> i have been thinking a lot about the rounding modes. the only way that >> could think about properly supporting them was to actually add new rtl a= nd >> tree operations that take the rounding mode as an extra parameter. i = think >> that this is going to be the only way to support both the static and dyn= amic >> models. This will be ugly, but having just finished the wide int patch= it is >> natural to say "how bad could it be?" some ports will want to support = this >> and some will not. >=20 > My starting point is to presume that any port with hardware floating-poin= t=20 > exceptions and rounding modes should support this. But since ports would= =20 > probably need to change anyway to ensure operations do raise the right=20 > exceptions, and to ensure that the machine-independent compiler can tell= =20 > which registers referred to in inline asm are part of the floating-point= =20 > exceptions / rounding modes state, maybe it wouldn't be so bad if they=20 > also need to change their instruction descriptions to describe the=20 > involvement of exceptions and rounding modes explicitly. (You do need to= =20 > handle the case of exceptions and rounding modes with software floating=20 > point, i.e. libcalls implicitly using them; this applies to powerpc-linux= =20 > soft float at least.) >=20 > Of course many target architecture ports are for architectures without=20 > hardware floating point, and without any exception or rounding mode=20 > support, and these issues don't arise for them. >=20 > (When I say above certain things are the main difficulty I mean they are= =20 > the only things with real design issues that I see. Lots of other issues= =20 > arise such as: >=20 > (a) writing thorough testcases for individual operations working properly= =20 > with exceptions and rounding modes in various contexts (I could probably= =20 > do that at least for basic arithmetic in a week or two; properly it shoul= d=20 > be done for every IEEE operation for which GCC allows a built-in function= =20 > to be expanded inline); >=20 > (b) going through transformations to review whether they are correct for= =20 > exceptions and rounding modes (a good starting point would be all=20 > references to e.g. HONOR_SIGN_DEPENDENT_ROUNDING, HONOR_NANS and=20 > flag_trapping_math, many of which are likely not checking quite the right= =20 > condition, although transformations with no such checks are harder to=20 > find); >=20 > (c) avoiding spurious exceptions from libgcc functions e.g. converting=20 > floating-point to DImode; >=20 > (d) ensuring the right exceptions from converting floating-point to=20 > bit-fields; >=20 > (e) converting the standard pragmas to appropriate IR describing what=20 > transformations are permitted on what code; >=20 > (f) if you do Annex G as well, the ABI for _Imaginary argument passing. >=20 > When you get into static rounding modes, as described in TS 18661-1, ther= e=20 > are a few more issues; e.g.: >=20 > (g) supporting both architectures that can encode rounding modes in=20 > instructions, and those where the rounding mode needs swapping at runtime; >=20 > (h) allowing library headers to define macros for standard library=20 > functions that cause them to use the constant rounding mode; >=20 > (i) ensuring that macros have the correct value in all constant= =20 > rounding modes, which is easy if they use hex floats, but if you allow th= e=20 > combination of C90 mode with constant rounding modes then you need long=20 > decimal expansions of those macros, so maybe that combination should be=20 > disallowed. >=20 > Those are examples of miscellaneous issues that I generally expect could= =20 > be addressed by lots of incremental patches without tricky overall design= =20 > issues. More would probably come up in a full analysis / design process= =20 > of how to do a high-quality implementation of C99/C11 Annex F/G and TS=20 > 18661-1.) >=20 The fp exceptions raise some very tricky issues with respect to gcc and opt= imization. On many machines, noisy does not mean to throw an exception,= it means that you set a bit and then check later. If you try to model t= his kind of behavior in gcc, you end up pinning the code so that nothing = can be moved or reordered.=20=20=20 to get this right gcc needs something like a monotonic dependency which wou= ld allow reordering=20=20=20=20=20 and gcc has nothing like this. essentially, you need way to say that all o= f these insns modify the same variable, but they all just move the value in= the same direction so you do not care what order the operations are perfor= med in. that does not mean that this could not be added but gcc has nothi= ng like this. however, even on the machines where you throw an exception, most people wil= l at least like an option where the exception can be out of order.=20=20=20= =20 going back to the rounding modes issue, there is a huge range in the archit= ectural implementation space. you have a few that are pure dynamic, a few = that are pure static and some in the middle that are just a mess. a lot o= f machines would have liked to support fully static, but could not fit the = bits to specify the rounding modes into the instruction. my point here is= you do need to at least have a plan that will support the full space even = if you do this with a 1000 small patches. > --=20 > Joseph S. Myers > joseph@codesourcery.com