Richard Sandiford <rdsandif...@googlemail.com> writes: > Matthew Fortune <matthew.fort...@imgtec.com> writes: > > Maciej W. Rozycki <ma...@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
