Volunteering/Consulting for libm Development in glibc

[Joseph Myers]

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