Re: [RFC, MIPS] Relax NaN rules

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Tue, 18 Mar 2014, Matthew Fortune wrote:

> 1) There is no way to mark a module as "don't care/not relevant". At a 
> minimum this could be done via inspection of the GNU FP ABI attribute 
> and when its value is 'Any' then NaNs don't matter. Better still would 
> be that modules with floating point only require a certain NaN state if 
> they use functions like __builtin_[s}nan. This would partially reduce 
> the impact of the strict NaN checks.

In general you can't tell whether a module cares.  It could have an 
initializer 0.0 / 0.0, without having any function calls involving 
floating point (so in principle being independent of hard/soft float, but 
not of NaN format).  Or it could be written with knowledge of the ABI to 
do things directly with bit patterns (possibly based on a configure test 
rather than __mips_nan2008).  The concept of a don't-care module is 
meaningful, but while heuristics can reliably tell that a module does care 
(e.g. GCC generated an encoding of a NaN bit-pattern, whether from 
__builtin_nan or 0.0 / 0.0) they can't so reliably tell that it doesn't 
care (although if it doesn't contain NaN bit-patterns, or manipulate 
representations of floating-point values through taking their addresses or 
using unions, you can probably be sure enough to mark it as don't-care - 
note that many cases where there are calls with floating-point arguments 
and results, but no manipulation of bit-patterns and no NaN constants, 
would be don't-care by this logic).

-- 
Joseph S. Myers
joseph@codesourcery.com