[PATCH] Don't do double divide in powf.

[Craig Howland]

On 12/12/2017 08:04 AM, Corinna Vinschen wrote:
> On Dec 11 19:45, Jim Wilson wrote:
>> Similar to the previous powf patch, we have a double 0.0/0.0 divide being
>> used to generate a NaN, which on a single float only target pulls in divdf3.
>> wf_log.c calls nan instead.  I fixed powf to do the same.
>>
>> With this patch, and a small testcase, I see
>>
>> gamma02:2368$ ls -lt a.out*
>> -rwxrwxr-x 1 jimw jimw 32912 Dec 11 19:35 a.out
>> -rwxrwxr-x 1 jimw jimw 46992 Dec 11 18:54 a.out.unpatched
>> gamma02:2369$
>>
>> So the patched code is about 70% of the size of the unpatched code.
>>
>> This was tested with the testcase included below, and a newlib make check.
>>
>> Jim
>>
>> 	newlib/
>> 	* libm/math/wf_pow.c (powf): Call nan instead of double 0.0/0.0.
>> ---
>>   newlib/libm/math/wf_pow.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/newlib/libm/math/wf_pow.c b/newlib/libm/math/wf_pow.c
>> index be453558b..1e0447173 100644
>> --- a/newlib/libm/math/wf_pow.c
>> +++ b/newlib/libm/math/wf_pow.c
>> @@ -108,7 +108,7 @@
>>   		    if (_LIB_VERSION == _SVID_)
>>   		        exc.retval = 0.0;
>>   		    else
>> -		        exc.retval = 0.0/0.0;	/* X/Open allow NaN */
>> +		        exc.retval = nan("");	/* X/Open allow NaN */
> As far as I can see, that still pulls in an unnecessary function call,
> nan().
>
> What about using NAN?  That's basically __builtin_nanf("") and usually
> resolves without function call on any platform.
No to either of the above.  The 0/0 construct is to cause a floating point 
"invalid" exception, which the functions do not do.  (The divide has to be done 
at runtime to cause the exception.)Â  The double divide can be made float by 
changing it to 0.0F/0.0F.
Craig