Volunteering/Consulting for libm Development in glibc

[Ayan Shafqat]

All:

Thank you very much for the reply.

On Mon, Feb 17, 2025 at 06:06:30PM +0000, Joseph Myers wrote:
> On Mon, 17 Feb 2025, Adhemerval Zanella Netto wrote:
...
> Note that most of those are among the more complicated functions to 
> implement because of the integer arguments (though I think they can all 
> still be implemented in a type-generic way, so avoiding the need for five 
> separate implementations for five separate formats including ldbl-128ibm, 
> but such a type-generic implementation may not be very efficient).  Also I 
> think Paul's testing of error bounds doesn't cover functions with integer 
> arguments.

I am biased towards using different implementation for different
bit-types. Yes, it can be cumbersome. But, it offers greater
flexibility. For example, sinf() will require less terms of Taylor
series than sin(), and sinl() will require more terms than sin(). There
are more examples like this where it makes sense to have a dedicate
area for implementing over different bit types.

> Adding support for _Float16, which I haven't started on yet, would also be 
> a rather complicated change to ensure the support is completed everywhere 
> in glibc (although there most functions, apart from a few such as fmaf16 
> with double-rounding issues, can initially be implemented as wrappers for 
> float functions then be changed incrementally to more efficient 
> implementations).

I do have access to ARM (Aarch64) CPUs that are capable of processing
_Float16. I should be able to help there. On the x86_64 side, the only
machine that has *some* _Float16 support would be an Alderlake CPU,
which can only convert _float16 to _Float32 in hardware, and do the
internal calculation in _Float32. What is the goal for supporting
_Float16 for machines without FP16 hardware? If the goal is to emulate,
then yes, I can see how it may get very complicated.

> FE_TONEARESTFROMZERO for RISC-V would also be quite complicated, again 
> with changes in lots of places to ensure it's properly supported 
> everywhere that currently has logic or tests to cover the different 
> rounding modes.

Yes, rounding-modes are one of the most complicated things someone has
to deal with. As I don't have a RISC-V machine, it may be harder to
contribute to this task.

----

On Mon, Feb 17, 2025 at 02:31:26PM -0300, Adhemerval Zanella Netto wrote:
> >   * Improve current implementations, which is something I am focusing lately.
> >     I am currently evaluating the CORE-MATH project, and I am already integrated
> >     a lot of they implementation on glibc. There are still a lot of work to do,
> >     mainly to check on double and long double (only x86_64 afaik).    

Thank you, Adhemerval! I was not aware of core-math, I can do a quick
checkout and see if I can build the code on my machine. I can also be
reached on IRC (ashafq on oftc) for a quick message.

Best regards,
Ayan