This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [RFC, MIPS] Relax NaN rules


Joseph Myers <joseph@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]