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 >
