This is the mail archive of the
mailing list for the GCC project.
RE: [RFC, MIPS] Relax NaN rules
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Richard Sandiford <rdsandiford at googlemail dot com>, "macro at codesourcery dot com" <macro at codesourcery dot com>, "dalias at aerifal dot cx" <dalias at aerifal dot cx>, "Andrew Pinski (pinskia at gmail dot com)" <pinskia at gmail dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Rich Fuhler <Rich dot Fuhler at imgtec dot com>, "Moore, Catherine (Catherine_Moore at mentor dot com)" <Catherine_Moore at mentor dot com>
- Date: Tue, 18 Mar 2014 15:06:16 +0000
- Subject: RE: [RFC, MIPS] Relax NaN rules
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B023534C5168 at LEMAIL01 dot le dot imgtec dot org> <Pine dot LNX dot 4 dot 64 dot 1403181418140 dot 29154 at digraph dot polyomino dot org dot uk>
Joseph Myers <email@example.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?