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

[Richard Allen <rsaxvc@rsaxvc.net>]

> 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