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...
> 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.
Thanks,
Richard
