public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: Joel Sherrill <joel@rtems.org>
To: Newlib <newlib@sourceware.org>
Subject: Re: [PATCH newlib v1 0/4] Add FreeBSD long double functions
Date: Wed, 24 Aug 2022 08:40:45 -0500	[thread overview]
Message-ID: <CAF9ehCVSHjt-9820Ba6mCLrya9Br13CuCOqMBmNja1crps6K6g@mail.gmail.com> (raw)
In-Reply-To: <YwXu0iVmbD8RfnfZ@calimero.vinschen.de>

On Wed, Aug 24, 2022 at 4:26 AM Corinna Vinschen <vinschen@redhat.com>
wrote:

> On Aug 22 17:50, Joel Sherrill wrote:
> > Hi
> >
> > To be clear, this is a V1 for review. It actually does **NOT**
> > add every long double math method from FreeBSD. That would add
> > unnecessary bulk to this patch set at this point.
> >
> > The FreeBSD long double code requires there to be an architecture
> > specific _fpmath.h file. This is only available for a handful of
> > architestures. Further, LDBL does EQ DBL on many architectures.
> > The FreeBSD long double code will **NOT** compile if there isn't
> > an _fpmath.h file. Thus, the overall approach is:
> >
> >   if architecture has _fpmath.h
> >      use FreeBSD long double code in libm/common/ldbl
> >   else
> >      use existing long double code
>
> Erm... Did you actually read my last reply?


Yes. If we do that, we end up with long double support on 8
architectures and lose it immediately on all others. On the
18 RTEMS target architectures,

+ Current: long double support on 12
+ Proposed: long double support on all
+ Delete ldbl=dbl implementation: 8 would have long double


We should really not add YA
> code path.  Merging the FreeBSD long double functions should work for
> basically all supported arches.  We only have to create our own
> _fpmath.h supporting all arches based on LDBL_MANT_DIG, isn't it?
>

It should if someone creates all the _fpmath.h headers. There are 61
directories under libc/machine. That leaves 53 _fpmath.h headers to
complete and most are likely ldbl==dbl. That is up to 53 target
architectures
which would lose the long double math APIs in libm.a.

Honestly, I don't mind long term planning to delete them but I was
thinking this approach improves the current situation a lot since it will
support the targets which really have long double support. It leaves
in place support for where ldbl==dbl with no change in available APIs.
It is a net win for users.

If there is a target with long double which doesn't have a FreeBSD
_fpmath.h file, then there is value in creating it.  Honestly, unless
someone
can script writing the missing 50+ _fpmath.h files, I am not comfortable
or eager to dive in. Ignoring the lack of time to so.

This approach works and doesn't abandon the targets which the
ldbl==dbl method works for.

--joel


>
>
> Corinna
>
>

WARNING: multiple messages have this Message-ID
From: Joel Sherrill <joel@rtems.org>
To: Newlib <newlib@sourceware.org>
Subject: Re: [PATCH newlib v1 0/4] Add FreeBSD long double functions
Date: Wed, 24 Aug 2022 08:40:45 -0500	[thread overview]
Message-ID: <CAF9ehCVSHjt-9820Ba6mCLrya9Br13CuCOqMBmNja1crps6K6g@mail.gmail.com> (raw)
Message-ID: <20220824134045.dW7oO88p4n-1yQqigYj0SZod9Jmi0JlCYQBC0kv11to@z> (raw)
In-Reply-To: <YwXu0iVmbD8RfnfZ@calimero.vinschen.de>

[-- Attachment #1: Type: text/plain, Size: 2346 bytes --]

On Wed, Aug 24, 2022 at 4:26 AM Corinna Vinschen <vinschen@redhat.com>
wrote:

> On Aug 22 17:50, Joel Sherrill wrote:
> > Hi
> >
> > To be clear, this is a V1 for review. It actually does **NOT**
> > add every long double math method from FreeBSD. That would add
> > unnecessary bulk to this patch set at this point.
> >
> > The FreeBSD long double code requires there to be an architecture
> > specific _fpmath.h file. This is only available for a handful of
> > architestures. Further, LDBL does EQ DBL on many architectures.
> > The FreeBSD long double code will **NOT** compile if there isn't
> > an _fpmath.h file. Thus, the overall approach is:
> >
> >   if architecture has _fpmath.h
> >      use FreeBSD long double code in libm/common/ldbl
> >   else
> >      use existing long double code
>
> Erm... Did you actually read my last reply?


Yes. If we do that, we end up with long double support on 8
architectures and lose it immediately on all others. On the
18 RTEMS target architectures,

+ Current: long double support on 12
+ Proposed: long double support on all
+ Delete ldbl=dbl implementation: 8 would have long double


We should really not add YA
> code path.  Merging the FreeBSD long double functions should work for
> basically all supported arches.  We only have to create our own
> _fpmath.h supporting all arches based on LDBL_MANT_DIG, isn't it?
>

It should if someone creates all the _fpmath.h headers. There are 61
directories under libc/machine. That leaves 53 _fpmath.h headers to
complete and most are likely ldbl==dbl. That is up to 53 target
architectures
which would lose the long double math APIs in libm.a.

Honestly, I don't mind long term planning to delete them but I was
thinking this approach improves the current situation a lot since it will
support the targets which really have long double support. It leaves
in place support for where ldbl==dbl with no change in available APIs.
It is a net win for users.

If there is a target with long double which doesn't have a FreeBSD
_fpmath.h file, then there is value in creating it.  Honestly, unless
someone
can script writing the missing 50+ _fpmath.h files, I am not comfortable
or eager to dive in. Ignoring the lack of time to so.

This approach works and doesn't abandon the targets which the
ldbl==dbl method works for.

--joel


>
>
> Corinna
>
>

  reply	other threads:[~2022-08-24 13:40 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-22 22:50 Joel Sherrill
2022-08-22 22:50 ` [PATCH newlib v1 1/4] Add infrastructure for incorporating FreeBSD long double methods Joel Sherrill
2022-08-22 22:50 ` [PATCH newlib v1 2/4] Makefile.in and configure: Regenerated Joel Sherrill
2022-08-22 22:50 ` [PATCH newlib v1 3/4] Split libm/common/frexpl.c into LDBL_EQ_DBL and long double versions Joel Sherrill
2022-08-22 22:50 ` [PATCH newlib v1 4/4] Makefile.in: Regenerated Joel Sherrill
2022-08-24  9:26 ` [PATCH newlib v1 0/4] Add FreeBSD long double functions Corinna Vinschen
2022-08-24 13:40   ` Joel Sherrill [this message]
2022-08-24 13:40     ` Joel Sherrill
2022-08-26 15:05     ` Corinna Vinschen
2022-08-26 15:45       ` Joel Sherrill
2022-08-26 15:45         ` Joel Sherrill
2022-08-26 17:45         ` Corinna Vinschen
2022-08-26 20:45           ` Jeff Johnston
2022-08-26 20:45             ` Jeff Johnston

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAF9ehCVSHjt-9820Ba6mCLrya9Br13CuCOqMBmNja1crps6K6g@mail.gmail.com \
    --to=joel@rtems.org \
    --cc=newlib@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).