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: [RFC][PATCH] New expf, exp2f, logf, log2f and powf implementations


On Wed, Aug 30, 2017 at 11:04 AM, Corinna Vinschen <vinschen@redhat.com> wrote:
> Hi Szabolcs,
>
> On Aug 30 15:18, Szabolcs Nagy wrote:
>> Based on code from https://github.com/ARM-software/optimized-routines/
>>
>> This patch adds a highly optimized generic implementation of expf,
>> exp2f, logf, log2f and powf.  The new functions are not only
>> significantly faster, but are also smaller, more accurate and fix
>> several correctness issues.  In order to achieve this, the algorithm
>> uses double precision arithmetic for accuracy, avoids divisions and
>> uses small table lookups to minimize the polynomials.  Special cases
>> are handled inline to avoid the unnecessary overhead of wrapper
>> functions and set errno to POSIX requirements.
>>
>> The new functions are added under newlib/libm/common and are
>> currently enabled for AArch64 and AArch32 with VFP format.  The
>> new functions are written in C99 and do not support non-IEEE
>> representations, mixed endian doubles or non-standard errno setting.
>> Targets can enable the new math code by undefining OBSOLETE_MATH.
>> Targets with a single precision FPU may still prefer the old
>> implementation. It was not clear what's the best way to add such
>> alternative math implementations to newlib so this is an RFC
>> patch and feedback is welcome.
>
> I'm not confident enough with math stuff to review this, so I'd
> rather like to defer to Jeff here.
>

I noticed that the ARM routines these are based on have an Apache
license.  I also
noted that you were the one who wrote the patches to that code that
has become the newlib implementations.
When modifying old code, you must keep the old license unless all the
authors and license owner agree to
relicense it.  In this case, ARM is the owner of the initial license
and so you probably should stick with the same license or
bounce it off your employer to make sure it is ok.

Can you comment on the correctness issues above?  Are there blatant
errors in the current implementation that should be
looked at (as opposed to rounding and "level of C Standard supported" issues)?

IMO, opting-in is reasonable considering that some platforms will not
meet the criteria and will break unless someone does the
work to go through and configure them properly.  For example, do all
the embedded compilers support hex floating-point constants by
this point?

-- Jeff J.

> However, two points:
>
> - Please send the patch as generated by `git format-patch'.  Ideally
>   as a patchset of smaller patches.
>
> - Why the OBSOLETE_MATH stuff?  If these implementations are generic
>   and sufficiently tested, wouldn't it make sense to enable them by
>   default without forcing other targets to enable the OBSOLETE_MATH
>   setting?
>
>
> Thanks,
> Corinna
>
> --
> Corinna Vinschen
> Cygwin Maintainer
> Red Hat


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