public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: Joel Sherrill <joel@rtems.org>
To: Newlib <newlib@sourceware.org>, Joel Sherrill <joel@rtems.org>,
	 Jeff Johnston <jjohnstn@redhat.com>
Subject: Re: [PATCH newlib v1 0/4] Add FreeBSD long double functions
Date: Fri, 26 Aug 2022 10:45:20 -0500	[thread overview]
Message-ID: <CAF9ehCUVeZZ5L_4XsfcH62KZp6OSRKJD98MZrzsxMO40ByhiOA@mail.gmail.com> (raw)
In-Reply-To: <YwjhKDtvIc3A1az1@calimero.vinschen.de>

On Fri, Aug 26, 2022 at 10:05 AM Corinna Vinschen <vinschen@redhat.com>
wrote:

> On Aug 24 08:40, Joel Sherrill wrote:
> > On Wed, Aug 24, 2022 at 4:26 AM Corinna Vinschen <vinschen@redhat.com>
> > wrote:
> > > > [...]
> > > >   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.
>
> No, I wrote, create a *single* _fpmath.h file with the massive amount
> of definitions (*all* seven) based on LDBL_MANT_DIG.
>
> There are very few special targets, like x86/x86_64 which need a tweak
> in the macros, most of the time the macros should be the same.
>
> Instead of having 61 files, only have one.  In theory there should be
> only two definitions for targets with LDBL_MANT_DIG == DBL_MANT_DIG
> to support little and big endian, more shouldn't be required.
>
> For all others, we already have *ieee*.h files with matching definitions
> which can be used as role models for the various (but few) definitions of
> union IEEEl2bits.  See, for instance, newlib/libc/include/machine/ieee.h.
>
> > 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.
>
> I never said to abandon these targets, but fwiw, I think you're
> overestimating the complexity to generate a single _fpmath.h
> file with matching definitions for these targes as well.  The
> information is basically already present in newlib.
>

So don't preserve the FreeBSD files as close to a direct copy
as possible?

Maybe I am overestimating it. I just don't see the single _fpmath.h
to rule them all with confidence like you do. I am not seeing the
set of parameters in my head which makes this generic with
some macros.

I'd appreciate help on this.


>
> Jeff, ping?  Your POV would be much appreciated here.
>

+1

I also have come across there needs to be a way to pick between ld80
and ld128 headers and implementation files. FreeBSD has them in
separate directories. Apparently their build system builds common
plus an architecture specific _fpmath.h and a choice of ld80/ld128
which adds at least two other header files

--joel

>
>
> Thanks,
> Corinna
>
>

  reply	other threads:[~2022-08-26 15:45 UTC|newest]

Thread overview: 11+ 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
2022-08-26 15:05     ` Corinna Vinschen
2022-08-26 15:45       ` Joel Sherrill [this message]
2022-08-26 17:45         ` Corinna Vinschen
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=CAF9ehCUVeZZ5L_4XsfcH62KZp6OSRKJD98MZrzsxMO40ByhiOA@mail.gmail.com \
    --to=joel@rtems.org \
    --cc=jjohnstn@redhat.com \
    --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).