From: "Keith Packard" <keithp@keithp.com>
To: Sebastian Huber <sebastian.huber@embedded-brains.de>,
Joseph Myers <joseph@codesourcery.com>
Cc: newlib@sourceware.org
Subject: Re: [PATCH 0/3] ARM with only 32-bit floats do not have fast 64-bit FMA
Date: Tue, 01 Sep 2020 22:25:02 -0700 [thread overview]
Message-ID: <87zh68agy9.fsf@keithp.com> (raw)
In-Reply-To: <c115d99f-e8fb-cd53-8269-f94f4f459a7b@embedded-brains.de>
[-- Attachment #1: Type: text/plain, Size: 906 bytes --]
Sebastian Huber <sebastian.huber@embedded-brains.de> writes:
> Our failing test is pretty basic, it just checks if fma() and fmaf()
> library functions are present as per C99. The glibc offers also a simple
> default implementation, for example:
>
> https://sourceware.org/git/?p=glibc.git;a=blob;f=math/s_fma.c;h=4d73af4f65d511594b2395d032a135721c578484;hb=HEAD
That implementation violates the spec though because it does two
binary operations involving two roundings, so you get a different answer
than you would with a true fma.
Is it better to implement the function incorrectly or better to not
implement it at all? If your hardware doesn't support the operation,
then doing this in software would be a lot slower than adapting your
algorithm to deal with a sequence of binary operations, even though you
will likely need more of them to reach the same accuracy.
--
-keith
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2020-09-02 5:25 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-08 22:34 Keith Packard
2020-08-08 22:34 ` [PATCH 1/3] libm: ARM without HW double does not have fast FMA Keith Packard
2020-08-08 22:34 ` [PATCH 2/3] libm: Detect fast fmaf support Keith Packard
2020-08-08 22:34 ` [PATCH 3/3] libm/machine/arm: Add optimized fmaf and fma when available Keith Packard
2020-08-10 9:30 ` [PATCH 0/3] ARM with only 32-bit floats do not have fast 64-bit FMA Corinna Vinschen
2020-08-10 14:43 ` Szabolcs Nagy
2020-08-10 15:19 ` Keith Packard
2020-08-10 19:06 ` Corinna Vinschen
2020-09-01 16:32 ` Sebastian Huber
2020-09-01 17:21 ` Sebastian Huber
2020-09-01 18:04 ` Sebastian Huber
2020-09-01 19:28 ` Keith Packard
2020-09-01 21:16 ` Joseph Myers
2020-09-01 23:06 ` Keith Packard
2020-09-02 4:41 ` Sebastian Huber
2020-09-02 5:25 ` Keith Packard [this message]
2020-09-02 5:35 ` Keith Packard
2020-09-02 17:12 ` Joseph Myers
2020-09-02 17:59 ` Sebastian Huber
2020-09-02 20:39 ` Keith Packard
2020-09-01 19:50 ` Keith Packard
2020-09-07 14:09 Eric Bresie
2020-09-07 17:16 ` Keith Packard
2020-09-07 20:16 ` Brian Inglis
2020-09-07 22:23 ` Keith Packard
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=87zh68agy9.fsf@keithp.com \
--to=keithp@keithp.com \
--cc=joseph@codesourcery.com \
--cc=newlib@sourceware.org \
--cc=sebastian.huber@embedded-brains.de \
/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).