This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]