Matthew Fortune <matthew.fort...@imgtec.com> writes: > 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
Ah, sorry. Reordering slightly... >> > 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. The problem is that if you disable the link-time check, you have to decide what the output encoding should be when the input encodings aren't consistent. At that point you lose any record of the correct encoding anyway and it isn't obvious which encoding should win. Without the "third mode", a system built with -mnan=legacy is likely to use legacy NaNs somewhere, so it becomes a question of whether using legacy NaNs for MSA-only TUs is worse than using a mixture of NaNs in the linked program. I don't see an obvious winner. > 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 sounds picky, but these two don't seem the same to me. On the one hand we have both flag settings but ignore them, while on the other we don't use the flag at all. And the latter seems better to me. Like you say, it'd be just like pretending that there was no way of tracking the NaN state to begin with. The easiest way to do that is to add a flag that either (a) stops the compiler emitting a .nan at all or (b) gets it to emit ".nan legacy" regardless of the actual encoding used. It's really just a slight variation on (2), the difference being that we might be using 2008 under the covers. IOW, -mstrict-nan or whatever would be a compiler flag rather than a linker flag. Thanks, Richard
