[PATCH] Avoid extra float->double conversion

[PATCH] Avoid extra float->double conversion

[Richard Allen]

[-- Attachment #1: Type: text/plain, Size: 100 bytes --]

Patch avoids an unnecessary float->double
conversion to save a small amount of codespace.

-Richard

[-- Attachment #2: 0002-Convert-rint-to-rintf.patch --]
[-- Type: text/x-patch, Size: 1109 bytes --]

From 2369a552cf62dfb53f14978587a338072f6abd2c Mon Sep 17 00:00:00 2001
From: Richard <rsaxvc@rsaxvc.net>
Date: Wed, 19 Apr 2017 18:37:17 -0500
Subject: [PATCH 2/2] Convert rint() to rintf()

This was causing an unnecessary increase
in precision, as well as additional function
calls to do float->double conversion on
platforms with only a single-precision FPU.
---
 newlib/libm/math/wf_pow.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/newlib/libm/math/wf_pow.c b/newlib/libm/math/wf_pow.c
index bd9de0ad0..5b79dd151 100644
--- a/newlib/libm/math/wf_pow.c
+++ b/newlib/libm/math/wf_pow.c
@@ -126,11 +126,11 @@
 		    if (_LIB_VERSION == _SVID_) {
 		       exc.retval = HUGE;
 		       y *= 0.5;
-		       if(x<0.0&&rint(y)!=y) exc.retval = -HUGE;
+		       if(x<0.0&&rintf(y)!=y) exc.retval = -HUGE;
 		    } else {
 		       exc.retval = HUGE_VAL;
                        y *= 0.5;
-		       if(x<0.0&&rint(y)!=y) exc.retval = -HUGE_VAL;
+		       if(x<0.0&&rintf(y)!=y) exc.retval = -HUGE_VAL;
 		    }
 		    if (_LIB_VERSION == _POSIX_)
 		        errno = ERANGE;
-- 
2.11.0

Re: [PATCH] Avoid extra float->double conversion

[Richard Allen]

[-- Attachment #1: Type: text/plain, Size: 306 bytes --]

There were a few more spots triggering double-precision math.
Attached patch updated to include comparisons and multiplies.

On Wed, Apr 19, 2017 at 6:53 PM, Richard Allen <rsaxvc@rsaxvc.net> wrote:
> Patch avoids an unnecessary float->double
> conversion to save a small amount of codespace.
>
> -Richard

[-- Attachment #2: 0002-Remove-extra-double-precision-rounding-and-compariso.patch --]
[-- Type: text/x-patch, Size: 1221 bytes --]

From 361abc1541b9a0f76a018a92b7e9d1e561cc35e8 Mon Sep 17 00:00:00 2001
From: Richard <rsaxvc@rsaxvc.net>
Date: Wed, 19 Apr 2017 18:37:17 -0500
Subject: [PATCH 2/2] Remove extra double-precision rounding and comparisons

Replace rint() with rintf() to avoid unnecessary
increase in precision, use float constants
to avoid doing compare, conversion, and multiplication
using doubles.
---
 newlib/libm/math/wf_pow.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/newlib/libm/math/wf_pow.c b/newlib/libm/math/wf_pow.c
index bd9de0ad0..b92e47d8e 100644
--- a/newlib/libm/math/wf_pow.c
+++ b/newlib/libm/math/wf_pow.c
@@ -125,12 +125,12 @@
 		    exc.arg2 = (double)y;
 		    if (_LIB_VERSION == _SVID_) {
 		       exc.retval = HUGE;
-		       y *= 0.5;
-		       if(x<0.0&&rint(y)!=y) exc.retval = -HUGE;
+		       y *= 0.5f;
+		       if(x<0.0f&&rintf(y)!=y) exc.retval = -HUGE;
 		    } else {
 		       exc.retval = HUGE_VAL;
-                       y *= 0.5;
-		       if(x<0.0&&rint(y)!=y) exc.retval = -HUGE_VAL;
+                       y *= 0.5f;
+		       if(x<0.0f&&rintf(y)!=y) exc.retval = -HUGE_VAL;
 		    }
 		    if (_LIB_VERSION == _POSIX_)
 		        errno = ERANGE;
-- 
2.11.0

Re: [PATCH] Avoid extra float->double conversion

[Craig Howland]

On 04/19/2017 08:03 PM, Richard Allen wrote:
> There were a few more spots triggering double-precision math.
> Attached patch updated to include comparisons and multiplies.
>
> On Wed, Apr 19, 2017 at 6:53 PM, Richard Allen <rsaxvc@rsaxvc.net> wrote:
>> Patch avoids an unnecessary float->double
>> conversion to save a small amount of codespace.
>>
>> -Richard
This is better than the first one, with the catch on the constants. Have you 
checked what was linked to be certain that no other double things are still 
there?  (Perhaps easier than inspecting the source.)

To be the most gung-ho, isnan() should be isnanf() throughout--saves a 
conversion and might avoid a double function being linked.  (It seems odd that 
it does have isfinitef(), but not isnanf().)

And just wondering, did you check all of the "f" functions?  (I'd guess so since 
your 0/0 patch edits multiple files, but better to know for sure.)  It would not 
be at all surprising if others (or even all) of the f forms had the same flaw.

Craig

Re: [PATCH] Avoid extra float->double conversion

[Richard Allen]

> And just wondering, did you check all of the "f" functions?  (I'd guess so
> since your 0/0 patch edits multiple files, but better to know for sure.)
> It would not be at all surprising if others (or even all) of the f forms had
> the same flaw.

Several of the "f" functions do similar things, mostly compares, but a few
arithmetic operations. This patch lets my particular project remove rint() at
link time. There will be a few more patches for those. There's also a few spots
where some operations are duplicated in if/elses, not sure if I'll go
after those.
Eventually, I'd like to get mathfp back up and running, but that's going to be a
much larger effort.

> This is better than the first one, with the catch on the constants. Have you
> checked what was linked to be certain that no other double things are still
> there?  (Perhaps easier than inspecting the source.)

The only float->double and double->float conversions remaining
are in the error handling when moving to/from exc.retval, exc.arg1, and
exc.arg2.

> To be the most gung-ho, isnan() should be isnanf() throughout--saves a
> conversion and might avoid a double function being linked.  (It seems odd
> that it does have isfinitef(), but not isnanf().)

In C99, isnan() became template-ey, and acts like a macro. newlib
implements it with __builtin_isnan(), which GCC inlines. Calling
isnanf() results in a function call, so I didn't change those.

-Richard

Re: [PATCH] Avoid extra float->double conversion

[Richard Allen]

> And just wondering, did you check all of the "f" functions?

I did finally go through the rest of the "f" functions. The
remaining float->double conversions are needed to support
matherr(). mathfp has extra float->double conversions
that should be fixed later, as part of fixing up mathfp.

Is there anything to do before merging this patch?


On Fri, Apr 21, 2017 at 8:30 AM, Richard Allen <rsaxvc@rsaxvc.net> wrote:
>> And just wondering, did you check all of the "f" functions?  (I'd guess so
>> since your 0/0 patch edits multiple files, but better to know for sure.)
>> It would not be at all surprising if others (or even all) of the f forms had
>> the same flaw.
>
> Several of the "f" functions do similar things, mostly compares, but a few
> arithmetic operations. This patch lets my particular project remove rint() at
> link time. There will be a few more patches for those. There's also a few spots
> where some operations are duplicated in if/elses, not sure if I'll go
> after those.
> Eventually, I'd like to get mathfp back up and running, but that's going to be a
> much larger effort.
>
>> This is better than the first one, with the catch on the constants. Have you
>> checked what was linked to be certain that no other double things are still
>> there?  (Perhaps easier than inspecting the source.)
>
> The only float->double and double->float conversions remaining
> are in the error handling when moving to/from exc.retval, exc.arg1, and
> exc.arg2.
>
>> To be the most gung-ho, isnan() should be isnanf() throughout--saves a
>> conversion and might avoid a double function being linked.  (It seems odd
>> that it does have isfinitef(), but not isnanf().)
>
> In C99, isnan() became template-ey, and acts like a macro. newlib
> implements it with __builtin_isnan(), which GCC inlines. Calling
> isnanf() results in a function call, so I didn't change those.
>
> -Richard