Implement C _FloatN, _FloatNx types [version 6]

[Joseph Myers]

On Wed, 31 Aug 2016, James Greenhalgh wrote:

> My concern with this is that the use of comparisons of FLT_EVAL_METHOD
> against 0 that Szabolcs is referring to is common and can have performance
> implications. In glibc for example, 
> 
>   static FLOAT
>   overflow_value (int negative)
>   {
>     __set_errno (ERANGE);
>   #if FLT_EVAL_METHOD != 0
>     volatile
>   #endif
>     FLOAT result = (negative ? -MAX_VALUE : MAX_VALUE) * MAX_VALUE;
>     return result;
>   }

Well, it's unavoidable that existing code may misbehave with a new value 
and need updating.  In the glibc case: use of volatile for excess 
precision is the old approach.  That function now (since my 2015-09-23 
patch) uses math_narrow_eval.  And math_narrow_eval is defined using an 
excess_precision macro in math_private.h.  So only the definition of that 
macro based on FLT_EVAL_METHOD needs updating for new values (and 
math_narrow_eval uses __asm__ ("" : "+m" (math_narrow_eval_tmp)); rather 
than volatile, which may be slightly better, though of course you want to 
avoid the load and store to memory in cases where there is no excess 
precision, or where truncating doesn't require a load and store).

(Of course if you want actual TS 18661-3 support for _Float16 in glibc 
that implies a strtof16 function and lots of other *f16 functions which 
also need to know about excess precision for _Float16 in the 
FLT_EVAL_METHOD = 0 case.  Even given the _Float128 support, supporting 
_Float16 in glibc would be a complicated project since no _Float16 
function implementations for glibc presently exist, although many could, 
correctly if suboptimally, wrap float versions.)

> On the other hand, it would be unfortunate if _Float16 could not use the
> ARMv8.2-A floating-point arithmetic instructions where they were available.

In the cases where the two FLT_EVAL_METHOD values are equivalent (e.g. 
where the result is assigned directly back to a _Float16 variable) of 
course you can anyway.

-- 
Joseph S. Myers
joseph@codesourcery.com