This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Implement C _FloatN, _FloatNx types [version 6]


On 31/08/16 18:26, Joseph Myers wrote:
> 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 

the goal was not to provide full support for some TS, but to
provide reasonable access to half precision floats from c.

it seems that the FLT_EVAL_METHOD change in TS 18661 was a
bad decision: existing code have to be modified to conform
to the new semantics. this situation could have been avoided
by introducing new macros or only changing behaviour when
the user requested it via __STDC_WANT_IEC_60559_TYPES_EXT__
(consistently with all other library changes..).

i think it makes sense to provide half precision support
on older c standards, so gcc should allow _Float16 without
excess precision and whatever __FLT_EVAL_METHOD setting
based on some cmd line option, so users can work around
this mess. (FLT_EVAL_METHOD < 0 would be fully conforming,
but it can still break existing code). user code can use
sizeof(_Float16_t), libc can get the real eval method
through some additional gcc specific macro.

> _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.
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]