[RFC, MIPS] Relax NaN rules

[Maciej W. Rozycki]

On Mon, 24 Mar 2014, Matthew Fortune wrote:

> Yes this is a lot simpler than the 3rd mode but disabling the NAN2008 ELF
> Flag checks is even more honest as that is what would happen at the
> kernel-userland boundary anyway, so why enforce it elsewhere.
> 
> I know I am pushing hard on this topic but I am significantly concerned
> about the impact a whole new build variant has for MIPS and signalling nan
> encoding is a rather trivial topic to cause it. 
> 
> Can anyone pinpoint something 'real' that would currently work but would
> fail if the snan encoding changed and was ignored/intermixed? Even if
> there is some genuine use-case then we can still give those
> users the ability to carefully control nan encoding with the work already
> done.

 What I'm concerned the most about is the matter is so obscure to people 
outside a narrow group of hardware/kernel/toolchain/library experts (that 
regrettably does not include distribution packagers) that once that "don't 
care" approach is set in the environment it'll be used universally because 
it's the path of least resistance that'll cause the least trouble for 
distributions.

 And then it'll hit another group who are expert on using IEEE maths for 
their scientific, etc. purposes and require correct results including NaN 
special cases, but then are not necessarily expertly enough or have no 
resources to rebuild their kernel/toolchain/library environment to their 
needs, or maybe even understand why exactly it does not work as they want. 
Plus the incorrect NaN case may actually show up only very infrequently, 
may require lots of effort to track down, and may eventually ruin their 
work.

 Whereas the compromise I proposed will always produce correct results and 
I believe will draw anyone's interested attention immediately to bad FP 
performance where the wrong binary is used for what hardware used supports 
and performance matters.  That with a suitable kernel message, e.g.:

<process foo>: Unsupported FP mode requested, switching to software FP 
emulation, please recompile with `-mnan=2008' for full performance.

or suchlike I believe will do and point people in the right direction (and 
likewise for `-mnan=legacy').

 The added benefit will be if a popular piece of software is going to 
suffer from that, then people will complain to their distribution supplier 
giving the vendor a chance to fix the problem up and supply the binary and 
any dependent libraries compiled in the desired NaN mode.  Pretty much 
like some libraries/executables already supplied by distribution vendors 
optimised for particular processor families or features, e.g. in the x86 
world (the `cmov' feature/instruction subset comes to my mind).

 Any real cons to doing this?  Besides having to invest some effort (but 
not really that much) into the kernel to implement this switching and 
reporting mechanism -- but in real world there's no free lunch and I think 
this investment will be worth it.

  Maciej