Volunteering/Consulting for libm Development in glibc

[Ayan Shafqat]

Joseph (and everyone):

Thank you very much for the detailed explanation and clarifications. I
am indeed eager to work on adding _Float16 support (and potentially
other C23-related libm functions) in glibc, but given the extent of the
work, it would require my full-time commitment (We can discuss this
separately). I plan to start by checking in with the #gcc team regarding
the compiler’s current status for _Float16, then move forward with
glibc-side tasks.

I also wanted to ask if there might be any formal or full-time
employment possibilities to undertake this project. I find this work
fascinating and believe it would benefit from dedicated attention. If
there is someone I could speak with or a particular process to follow
for such opportunities, I would greatly appreciate any guidance.

So far, I have checked out core-math and ran some of the tests. Great
work on the documentation side! I was pretty much up-to-speed within
15 minutes. My next steps will be:

- Coordinate with #gcc to see the status of _FloatN support via
  emulation. I am aware of software floating point library in libgcc,
  but I am not sure about the current status of different binary
  formats.
- Planning incremental changes to core-math (or libm) project ensuring
  glibc ABI consistency.

Please let me know if there are particular areas or functions you’d like
me to prioritize. I look forward to contributing to the development of
this support.

Best regards,
Ayan


On Mon, Feb 17, 2025 at 09:23:15PM +0000, Joseph Myers wrote:
> On Mon, 17 Feb 2025, Ayan Shafqat wrote:
> 
> > 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.
> 
> The basic principle is that we support a function at the same time across 
> all architectures, ABIs and floating-point formats.  To get this done in a 
> reasonable time (and noting that there are no glibc configurations that 
> support all the floating-point formats - no configuration supports both 
> the x86/m68k binary64-extended format (ldbl-96), and ldbl-128ibm), it's 
> generally convenient to add a function in a patch that contains all the 
> boilerplate changes (ABI test baselines, test inputs, etc.) but only one 
> implementation - with better implementations for particular formats then 
> able to be added later incrementally.  (But given limited interest in 
> ldbl-128ibm nowadays, it's quite likely no-one is going to add a better 
> implementation for that format, for example, in which case it will remain 
> using the type-generic implementation.)  The type-generic implementation 
> typically builds on top of other functions that already exist (some of 
> which may have format-specific implementations).
> 
> > > 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
> 
> I believe the first conversion support (F16C) was added in Ivy Bridge.
> 
> > 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.
> 
> This has little to do with hardware support, since the underlying 
> arithmetic is the compiler's problem.  What it does require is finding all 
> the tests (especially for string conversions etc.) that cover existing 
> formats and adding corresponding inputs also for the binary16 format, for 
> example - in libm, that includes going through auto-libm-test-in and 
> trying to add corresponding binary16 inputs where the tests try to cover 
> special cases for other formats (and also where applicable for manually 
> written tests in libm-test-*.inc).
> 
> (There are also other test considerations such as arranging for tests of 
> _Float16 on 32-bit x86 to run only when SSE is available, since the ABI 
> for _Float16 there requires SSE.)
> 
> The C standard expects that where _Float16 is supported in the compiler 
> (whether in hardware or not), it's also supported in the library.  glibc 
> has a particular set of functions supported for each ABI, so if we add 
> _Float16 functions to the glibc ABI for x86_64, that means they are 
> provided by glibc on x86_64 regardless of hardware support (and that GCC 
> 12 or later is then needed to build glibc for x86_64).
> 
> If we add _Float16 support at different times (different glibc versions) 
> on different architectures, and new libm functions are added between those 
> times, there is the additional complication of needing to add a MAX 
> operator for use in Versions files to determine the symbol version that 
> such _Float16 functions get on a given architecture.  (This is an argument 
> for completing all the other C23 libm functions - including the 
> string-to-encoding, string-from-encoding and encoding conversion 
> functions, and the fromfp type changes - before adding _Float16 support, 
> although that probably wouldn't avoid MAX support indefinitely given C2Y 
> could well add more libm functions.)
> 
> -- 
> Joseph S. Myers
> josmyers@redhat.com
> 

On Mon, Feb 17, 2025 at 09:23:15PM +0000, Joseph Myers wrote:
> On Mon, 17 Feb 2025, Ayan Shafqat wrote:
> 
> > 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.
> 
> The basic principle is that we support a function at the same time across 
> all architectures, ABIs and floating-point formats.  To get this done in a 
> reasonable time (and noting that there are no glibc configurations that 
> support all the floating-point formats - no configuration supports both 
> the x86/m68k binary64-extended format (ldbl-96), and ldbl-128ibm), it's 
> generally convenient to add a function in a patch that contains all the 
> boilerplate changes (ABI test baselines, test inputs, etc.) but only one 
> implementation - with better implementations for particular formats then 
> able to be added later incrementally.  (But given limited interest in 
> ldbl-128ibm nowadays, it's quite likely no-one is going to add a better 
> implementation for that format, for example, in which case it will remain 
> using the type-generic implementation.)  The type-generic implementation 
> typically builds on top of other functions that already exist (some of 
> which may have format-specific implementations).
> 
> > > 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
> 
> I believe the first conversion support (F16C) was added in Ivy Bridge.
> 
> > 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.
> 
> This has little to do with hardware support, since the underlying 
> arithmetic is the compiler's problem.  What it does require is finding all 
> the tests (especially for string conversions etc.) that cover existing 
> formats and adding corresponding inputs also for the binary16 format, for 
> example - in libm, that includes going through auto-libm-test-in and 
> trying to add corresponding binary16 inputs where the tests try to cover 
> special cases for other formats (and also where applicable for manually 
> written tests in libm-test-*.inc).
> 
> (There are also other test considerations such as arranging for tests of 
> _Float16 on 32-bit x86 to run only when SSE is available, since the ABI 
> for _Float16 there requires SSE.)
> 
> The C standard expects that where _Float16 is supported in the compiler 
> (whether in hardware or not), it's also supported in the library.  glibc 
> has a particular set of functions supported for each ABI, so if we add 
> _Float16 functions to the glibc ABI for x86_64, that means they are 
> provided by glibc on x86_64 regardless of hardware support (and that GCC 
> 12 or later is then needed to build glibc for x86_64).
> 
> If we add _Float16 support at different times (different glibc versions) 
> on different architectures, and new libm functions are added between those 
> times, there is the additional complication of needing to add a MAX 
> operator for use in Versions files to determine the symbol version that 
> such _Float16 functions get on a given architecture.  (This is an argument 
> for completing all the other C23 libm functions - including the 
> string-to-encoding, string-from-encoding and encoding conversion 
> functions, and the fromfp type changes - before adding _Float16 support, 
> although that probably wouldn't avoid MAX support indefinitely given C2Y 
> could well add more libm functions.)
> 
> -- 
> Joseph S. Myers
> josmyers@redhat.com
>