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: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: "Maciej W. Rozycki" <macro at codesourcery 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: Mon, 24 Mar 2014 22:12:41 +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> <alpine dot DEB dot 1 dot 10 dot 1403221217120 dot 23119 at tp dot orcam dot me dot uk> <6D39441BF12EF246A7ABCE6654B023534C982C at LEMAIL01 dot le dot imgtec dot org> <87txap40o2 dot fsf at talisman dot default>
Richard Sandiford <firstname.lastname@example.org> writes:
> Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> > Maciej W. Rozycki <email@example.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
> > that ignores nan encoding... but add a special symbol introduced by
> > the linker which the fenv code could use to warn when enabling
> > 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
> 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 -
> 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
> 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
> (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
> And at that point any automatic rules based on the library-level
> lose their value. Also, without a guarantee like that, it becomes
> hard for a user to know whether they will be affected by that
> or not.
> (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
> > require nan2008. (This is really just another way of masking the
> > 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