On 01/29/2018 12:51 PM, Joseph Myers wrote:
> On Mon, 29 Jan 2018, [email protected] wrote:
>
>>> What about powerpc __divkc3?
>>>
>>> What was the rationale for using soft-fp rather than adding appropriate
>>> built-in functions as suggested in a comment?
>> I had a version with built-in functions and I can restore it.
>>
>> Let's design what we want to use soft-fp or built-in function.
>> I'd prefer to use built-in functions but performance is in two times worse.
>>
>> The test below demonstrates performance degradation:
> So, this is comparing __builtin_frexp (extracting both exponent and
> mantissa, including appropriate handling of exponents of subnormal values)
> with just extracting the exponent and with no special handling of zero /
> infinity / NaN / subnormal values.
I compared with __builtin_ilogb. There is a same performance degradation.
> We need to consider what functionality is actually needed for this
> scaling, if we do wish to use such scaling based on integer exponents. If
> what's needed corresponds exactly to some standard functions such as ilogb
> and scalbn with all their special cases, then built-in versions of those
> standard functions may make sense.
The IEEE format for double is <sign : 1> <exponent : 11> <fraction :
52>.
We need a function like extract_exponent_field.
All standard function make an additional work to get exponent.
It is a reason why we see performance degradation.
% cat r2.c
#include <stdio.h>
int main(int argc, char** argv)
{
double d = 0x0.004p-1023;
printf("d=%-24.13a exp=%d\n", d, __builtin_ilogb(d));
return 0;
}
% gcc -O2 -lm r2.c ; ./a.out
d=0x0.0020000000000p-1022 *exp=-1033
*
-Vladimir
> If what's needed does not correspond
> to standard functions and does not need to handle such special cases,
> that's more of an indication for examining the representation in libgcc -
> but it's still necessary to handle the many different variant
> floating-point formats supported, or to safely avoid using the new code
> for formats it can't handle.
>
