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
