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 jos...@codesourcery.com