This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: patch to fix rtl documentation for new floating point comparisons

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

>> Paolo

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]