This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC, MIPS] Relax NaN rules
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: Matthew Fortune <Matthew dot Fortune at imgtec dot com>, Joseph Myers <joseph 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: Sat, 22 Mar 2014 12:35:38 +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> <6D39441BF12EF246A7ABCE6654B023534C596B at LEMAIL01 dot le dot imgtec dot org> <87bnwy634z dot fsf at talisman dot default>
On Sat, 22 Mar 2014, Richard Sandiford wrote:
> > 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?
>
> Maybe it's just me, but I don't understand your use case for (2).
> If 99% of users don't care about the different NaN encodings then
> why would they use a different -mnan setting from the default?
> Are you worried about potential future processors that only support
> 2008 NaNs? If so, then (a) you give good reasons why that seems like a
> misfeature and (b) I think we should instead tackle it by continuing
> to allow both -mnan settings for all processors. I.e. we simply wouldn't
> add any logic to check "is this processor/architecture compatible with this
> encoding?".
Such processors already exist I believe. Matthew will fill you in on the
details, but IIRC they are strapped at boot to either NaN mode that cannot
be switched at the run time, i.e. via CP1.FCSR (the NAN2008 bit is fixed
at 0 or 1 depending on the boot mode selected). Of course that means they
can still run legacy NaN code if strapped for the legacy NaN mode, but
it's up to the SOC/board hardware designer to decide which mode to choose
and we have no control over that.
I feel uneasy about silently producing wrong results, even if it's only
such a border case as for many the NaN is. Perhaps switching the kernel
into a full FP emulation mode for programs that have an unsupported NaN
requirement would be an option? That should be doable with a reasonable
effort and wouldn't affect programs that do not use the FPU at all, so no
need to rush rebuilding everything, just the FP-intensive software
packages.
Maciej