[libc-dev] Fwd: correctly rounded mathematical functions

[David Finkelstein via libc-dev]

On Wed, Jan 12, 2022 at 11:32 AM Paul Zimmermann via libc-dev <
libc-dev at lists.llvm.org> wrote:

>        Hi Siva,
>
> >  Are developers of llvm-libc interested by such functions?
> >
> > Yes!
>
> great to hear!
>
> >  If so, we could discuss what would be the requirements for integration
> >  in
> >  llvm-libc in terms of license, table size, allowed operations.
> >
> > With respect to license: The contributions should be under the LLVM
> license
> > and follow the LLVM libc coding style. We can help with setting up the
> > boiler plate and guide with respect to the coding style.
>
> we might consider multi-licensing but we'll try to avoid if possible.
>
> Would the MIT license be ok for inclusion in LLVM? According to
> https://en.wikipedia.org/wiki/License_compatibility it is more permissive
> than the Apache license, on which the LLVM is based, according to
> https://en.wikipedia.org/wiki/LLVM.
>

Unfortunately not.  The LLVM license is "Apache License v2.0 with LLVM
Exceptions" and the "LLVM Exceptions" part is rather important.

In LLVM-libc, you can find a directory containing AOR math routines
<https://github.com/llvm/llvm-project/tree/main/libc/AOR_v20.02> from Arm.
These were originally published by Arm on github under the MIT license (see
https://github.com/ARM-software/optimized-routines), and as much as we were
interested in that code we couldn't use it either. This usage/license
problem was resolved when someone from Arm (the copyright holder)
re-published the code into LLVM and put the code under the LLVM license.
This was done pretty much as a "source drop" so the code wasn't usable as
committed, but once it was in-tree we were able to take the code and modify
it as necessary to work for LLVM-libc.

Ideally we'd like to avoid this scenario a second time and I hope you
develop directly in LLVM though I understand if that's problematic for you
for your own licensing or other reasons.  I'm happy to discuss possible
paths forward with you.

Regards,

---- David

>
> > About table sizes: Since this is specifically about cr_* functions, I do
> not
> > think there should be any table size limitations to begin with. I would
> > imagine that you will continue to work on reducing the table sizes as
> they
> > can potentially impact runtime performance.
>
> ok, indeed once we get a first correctly rounding implementation for one
> function, we'll try to improve its efficiency and/or reduce the table
> sizes.
>
> > About allowed operations: I do not think there will be any restrictions
> here
> > as well. LLVM libc is a pick and choose libc. So, if someone does not
> want
> > some or all of cr_* functions, they can simply exclude them.
>
> great!
>
> > Hope this answers your questions. Feel free to ask if you have any more.
>
> yes thanks.
>
> Best regards,
> Paul
> _______________________________________________
> libc-dev mailing list
> libc-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/libc-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libc-dev/attachments/20220112/6739d5c2/attachment.html>