This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: patch to fix rtl documentation for new floating point comparisons
- From: Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>
- To: Kenneth Zadeck <zadeck at naturalbridge dot com>, Paolo Bonzini <bonzini at gnu dot org>, Joseph Myers <joseph at codesourcery dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 17 Feb 2015 10:07:32 +0000
- Subject: Re: patch to fix rtl documentation for new floating point comparisons
- Authentication-results: sourceware.org; auth=none
- References: <54D9063D dot 1000102 at naturalbridge dot com> <alpine dot DEB dot 2 dot 10 dot 1502092223140 dot 32543 at digraph dot polyomino dot org dot uk> <54D95C03 dot 1090904 at naturalbridge dot com> <alpine dot DEB dot 2 dot 10 dot 1502102141060 dot 31125 at digraph dot polyomino dot org dot uk> <54DFAF8C dot 6000906 at gnu dot org> <54E0C471 dot 1090704 at naturalbridge dot com>
On 15/02/15 16:08, Kenneth Zadeck wrote:
>
> On 02/14/2015 03:26 PM, Paolo Bonzini wrote:
>>
>> On 10/02/2015 22:46, Joseph Myers wrote:
>>> It may make sense to define LTGT as exactly !UNEQ, and so quiet, but the
>>> choice of definition is a matter of what's convenient for the
>>> implementation (and which choice you make determines which existing code
>>> in GCC should be considered incorrect).
>> It would be different from e.g. !UNLT and GE differing only in that UNLT
>> is quiet and GE is signaling. So it makes sense to me to keep LTGT as
>> signaling.
> while in theory, your argument is correct, in practice, this is not how
> people use this stuff and so i disagree.
>
> The interrupts are there to allow legacy code that does not know about
> nans to be "run"
> in a mode where the nans can be used to signal that things did not run
> well. Properly written floating point aware code never uses the
> interrupts. In that code, you want a rich set of comparisons which
> allow the programmer to efficiently deal with the fact that any
> comparison can go one of 4 possible ways.
>
> to support legacy code we need ne and eq to be quiet and lt gt le ge to
> be noisy. This is what the standards call for and this is what gcc
> delivers. Going beyond that for legacy code is a waste of time.
>
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.
I suspect there are two ways we could deal with that: add new comparison
RTL codes to distinguish the cases; or use something like the RTL /v bit
on a comparison to indicate that it should be signalling.
Of the two, the latter would probably be easiest to implement in a
backwards compatible manner (backends not understanding /v would
continue to use their existing code paths), but it would still take a
fair amount of rejigging in the mid end to fully preserve the signalling
nature of comparisons: there are many places where just RTX_CODE is
available and a new pattern is generated from that. The first method
would require all back-ends to be updated pretty much simultaneously to
handle the new RTL codes.
> kenny
R.
>> Paolo
>