correctly rounded mathematical functions

A message from Paul Zimmermann about the CORE-MATH project to LLVM-libc developers.

Hi Alexei, Christoph, Jean-Michel and Paul,

Are developers of llvm-libc interested by such functions?

Yes!

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.

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.

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.

Hope this answers your questions. Feel free to ask if you have any more.

Thanks,
Siva Chandra

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.

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

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 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