> From: Matthew Fortune > Sent: Tuesday, March 18, 2014 08:06 > To: Joseph Myers > Cc: Richard Sandiford; ma...@codesourcery.com; dal...@aerifal.cx; Andrew > Pinski (pins...@gmail.com); gcc@gcc.gnu.org; Rich Fuhler; Moore, Catherine > (catherine_mo...@mentor.com) > Subject: RE: [RFC, MIPS] Relax NaN rules > > Joseph Myers <jos...@codesourcery.com> writes: > > > 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). > > Thanks Joseph. I guess I'm not really pushing to have don't-care supported as > it would take a lot of effort to determine when code does and does not care, > you rightly point > out more cases to deal with too. I'm not sure if the > benefit would then be worth it or not as there would still be modules which > do and do not care about old and new NaNs > so it doesn't really relieve any > pressure on toolchains or linux distributions. The second part of the > proposal is more interesting/useful as it is saying I don't care about the > impact of getting NaN encoding wrong and a tools vendor/linux distribution > then gets to make that choice. Any comments on that aspect? > > Regards, > Matthew
Hi Joseph, as I remember from conversations last year, there is also an issue if the programmer specifically enables the FPU exceptions. If the FPU, kernel emulator, or bare-metal emulator (CS3's for example) did raise a signaling NaN, then the intermixing couldn't be done. As I remembering this correctly? I ask this for another reason as well: since we're adding IFUNC capability to MIPS, we may need to harden the dynamic loader to protect $f12 and $f14. If signaling NaN was raised on the load, then we have more problems to deal with... -rich
