This is the mail archive of the 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

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 


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