Re: [PATCH] MIPS: IEEE 754-2008 NaN encoding features

[Richard Sandiford <rdsandiford at googlemail dot com>]

"Maciej W. Rozycki" <macro@codesourcery.com> writes:
> On Sat, 8 Dec 2012, Richard Sandiford wrote:
>
>> >  As many of you have been aware it has been a long practice for software 
>> > using IEEE 754 floating-point arithmetic run on MIPS processors to use an 
>> > encoding of Not-a-Number (NaN) data different to one used by software run 
>> > on other processors.  And as of IEEE 754-2008 revision this encoding does 
>> > not follow one recommended in the standard, as specified in section 6.2.1, 
>> > where it is stated that quiet NaNs should have the first bit (d1) of their 
>> > significand set to 1 while signalling NaNs should have that bit set to 0, 
>> > but MIPS software interprets the two bits in the opposite manner.
>> >
>> >  An upcoming MIPS Architecture revision will provide for processors that 
>> > support the IEEE 754-2008 preferred NaN encoding format.  As the two 
>> > formats (further referred to as "legacy NaN" and "2008 NaN") are 
>> > incompatible to each other, tools will have to provide support for the two 
>> > formats to help people avoid using incompatible binary modules.  Here is 
>> > the binutils part.
>> >
>> >  Two new entities have been added to support static and dynamic linking.  
>> > For the former a set of new ELF file attribute values have been defined.  
>> > For the latter a new ELF file header flag has been defined.  These changes 
>> > are described in detail below.
>> 
>> But an ELF flag supports static and dynamic linking on its own.
>> Encoding the same information in the attribute seems redundant,
>> and makes the implementation a fair bit more complicated.
>
>  Sources need to be annotated as NaN encodings will be present within them 
> -- .gnu_attribute is suited for this purpose.  The header flag is required 
> so that the kernel configures the FPU appropriately or rejects binaries 
> that are incompatible with hardware being used that does not support the 
> NaN encoding requested and also so that ld.so refuses to load incompatible 
> modules together.
>
>  Do you have any better proposal?  I can drop the setting on the header 
> flag on relocatables and keep it on final binaries only if that made you 
> feel better.

Well, I don't agree the source _needs_ to be annotated with the NaN encoding.
The annotation is as easy to forget as the command-line option.  However,
I realise that's a bit of a religious debate, and that others think that:

   gcc -c foo.c -mfoo -mblah -mfrob

ought to be equivalent to:

   gcc -S foo.c -mfoo -mblah -mfrob
   as foo.s

Although it doesn't seem that important to me, I've no objection if
there's a concerted attempt to move in that direction.  The approach
taken in the patch is different though.  When the source sets an IEEE
NaN FP attribute, the patch also requires -mnan2008 to be passed on
the command line and reports an error if the user forgets.

If we require -mnan2008 to be passed anyway, then all the source
annotation does is provide a bit of extra error checking.  I'm not
convinced that that check is worth all the extra complexity.  The
file-level PIC, ABI and architecture header flags are all set from
similar, unchecked, options, and I'm not aware that passing the wrong
options is a common source of error.  Either way, the consistency
check should be contained within the assembler, whereas using
".gnu_attribute" for the source annotation requires an underlying
attribute flag that must at all times mirror the header flag.

If instead we want to support source annotation without command-line options
the "as foo.s" stance above), and command-line options without source
annotation (e.g. for assembler source that doesn't use FP), then how about
having a command-line option:

  -mnan=2008|legacy

and a directive:

  .nan 2008|legacy

Both would act in the same way and it would be an error to contradict
a previous setting.  (I wondered about ".set nan..." instead of ".nan",
but this doesn't really work like other .set options, and shouldn't for
example be used in a push/pop sequence.)  Of course, if neither are used,
we assume legacy.

Richard