public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>
To: newlib@sourceware.org
Subject: Re: [PATCH 0/3] ARM with only 32-bit floats do not have fast 64-bit FMA
Date: Mon, 7 Sep 2020 14:16:50 -0600	[thread overview]
Message-ID: <92283f3b-46a4-6ba2-1d07-a48c2db236cb@SystematicSw.ab.ca> (raw)
In-Reply-To: <874ko95wyf.fsf@keithp.com>

On 2020-09-07 11:16, Keith Packard via Newlib wrote:
> Eric Bresie via Newlib <newlib@sourceware.org> writes:
> 
>> Not directly related (and as I’m not really an expert on these things, nor able to change in any way) but was looking at the code mentioned and saw line like:
>>
>> if (x == 0.0 || y == 0.0)
>>
>> return (x * y + z);
>>
>> If either x or y is zero would it be better to just return z and avoid
>> an extra multiplication operation here?
> 
> You want to compute the correct result and get the right exceptions in
> all of the delightful IEEE754 corner cases (e.g. 0 × ∞). It's easier to
> just execute the two operations than to try and synthesize the right
> result (which is implementation-dependent in the case of 0 × ∞ +
> qNaN). The key here is that if x or y is zero, then you won't lose any
> intermediate precision by performing the operation this way.

Can't the "super-smart" compiler use that information to work around your
careful approach by conditionally skipping the FMA and conditionally return just
z, or even unconditionally return z, as C makes no guarantees?
And couldn't the "super-smart" instruction scheduler do similar at the hardware
level?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]

  reply	other threads:[~2020-09-07 20:16 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-07 14:09 Eric Bresie
2020-09-07 17:16 ` Keith Packard
2020-09-07 20:16   ` Brian Inglis [this message]
2020-09-07 22:23     ` Keith Packard
  -- strict thread matches above, loose matches on Subject: below --
2020-08-08 22:34 Keith Packard
2020-08-10  9:30 ` 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
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

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=92283f3b-46a4-6ba2-1d07-a48c2db236cb@SystematicSw.ab.ca \
    --to=brian.inglis@systematicsw.ab.ca \
    --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).