[RFC, MIPS] Relax NaN rules

[Matthew Fortune]

Richard Sandiford <rdsandiford@googlemail.com> writes:
> Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> > Maciej W. Rozycki <macro@codesourcery.com> writes:
> >> 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?
> >
> > MSA requires nan2008.
> 
> Ah, OK.
> 
> > A couple of ideas to address some of the various concerns:
> >
> > 1) As per my original proposal of allowing the tools to be built in a
> mode
> >    that ignores nan encoding... but add a special symbol introduced by
> >    the linker which the fenv code could use to warn when enabling
> exceptions
> >    that could trigger incorrectly.
> 
> The problem with a third mode is that, as discussed upthread, there's no
> way in general to tell whether a given bit of code cares about sNaNs or
> not.
> So the third mode is really just an assertion by the user that NaN
> encodings don't matter.  I think in that case a separate mode is only
> useful if:
> 
> (a) the entire single-variant base system is built in don't-care mode
>     (a bit like it would be built with -mfpxx, which is what makes -
> mfpxx
>     useful).  But is it really feasible for the system to be completely
>     agnostic about the NaN encoding?  I assume any long double emulation
>     code (if using the normal form of n32/64) and any float parsing code
>     would then need to look at the FCSR before generating a NaN.
>     NaNs in C initialisers would be disallowed.  Etc.  These are rules
>     that would need to be followed throughout the codebase, even the
>     target-independent parts.  Would a portable codebase really be
> willing
>     to accept that for a MIPS oddity?
> 
>     If instead some routines in some system libraries assume a
> particular NaN
>     encoding but the library binaries themselves claim to be "don't
> care"
>     (on the basis that everything is OK if you avoid those routines)
>     then we lose the ability to say that using a "don't care" library
>     will not in itself cause your application to depend on NaN
> encodings.
>     And at that point any automatic rules based on the library-level
> markup
>     lose their value.  Also, without a guarantee like that, it becomes
> very
>     hard for a user to know whether they will be affected by that
> encoding
>     or not.
> 
> and
> (b) the user has to explicitly say that they don't care, rather than it
>     being implied by things like -mmsa.  I think you wanted it the other
>     way around, with "don't care" being the default and the user having
>     to say explicitly that they care.
> 
>     Otherwise, all the third mode does is cause the system to reject any
>     binary that is careful enough to say that it wants one encoding over
>     another and relies on no feature that would stop it running on the
>     processor otherwise.  (This excludes MSA-only binaries, for example,
>     since they would be rejected on non-MSA systems anyway.)
> 
> Without (a) and (b) it seems like a lot of complication for a very
> narrow use case.  If we have a system built for one encoding and a
> processor that uses another then in some ways...

I don't think I was clear enough here, I agree with your points above about
what would be necessary to support a 3rd 'I don't care' mode. I don't think
this effort is really worth it either

I am more interested in giving tools builders the option to produce tools
that just ignore NAN2008 ELF flags (as if all the work on tracking nan
encodings were never done). I know this leaves a sour taste as we are
allowing inconsistencies to exist but I'm not sure there are real world
cases that matter here.

> > 2) Allow MSA to be built with nan1985 even though the hardware will
> always
> >    require nan2008. (This is really just another way of masking the
> problem
> >    but is possibly even less safe as the objects would have no record
> of the
> >    'correct' encoding requirement.
> 
> ...this seems more honest about what we're actually doing.  It's also an
> awful lot simpler.

Yes this is a lot simpler than the 3rd mode but disabling the NAN2008 ELF
Flag checks is even more honest as that is what would happen at the
kernel-userland boundary anyway, so why enforce it elsewhere.

I know I am pushing hard on this topic but I am significantly concerned
about the impact a whole new build variant has for MIPS and signalling nan
encoding is a rather trivial topic to cause it. 

Can anyone pinpoint something 'real' that would currently work but would
fail if the snan encoding changed and was ignored/intermixed? Even if
there is some genuine use-case then we can still give those
users the ability to carefully control nan encoding with the work already
done.

Regards,
Matthew