public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Joseph Myers <joseph@codesourcery.com>
To: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Cc: "michael.hudson@canonical.com" <michael.hudson@canonical.com>,
	'GNU C Library' <libc-alpha@sourceware.org>
Subject: Re: [PATCH] Ensure calculations happen with desired rounding mode in y1lf128
Date: Mon, 15 Aug 2022 20:59:53 +0000	[thread overview]
Message-ID: <alpine.DEB.2.22.394.2208152055090.311521@digraph.polyomino.org.uk> (raw)
In-Reply-To: <AM5PR0801MB16686F7E4FC42758D0C6930E83679@AM5PR0801MB1668.eurprd08.prod.outlook.com>

On Fri, 12 Aug 2022, Wilco Dijkstra via Libc-alpha wrote:

> All math functions using the SET_RESTORE_ROUND macros will need similar
> barriers. Note that it is feasible to remove these macros altogether and fix
> any issues (a slightly larger ULP is acceptable for non-nearest rounding).
> Given rounding mode changes are generally expensive, this also improves
> performance (though that may not be important for 128-bit floats).

This one is a case where SET_RESTORE_ROUND is used to reduce error 
accumulation to keep the errors within the bounds accepted by the 
testsuite (see bug 16824).  In such cases, it may indeed be possible to 
change the algorithm to one that has less total error accumulation 
possible in any rounding mode so the results are sufficiently accurate 
independent of rounding mode without needing SET_RESTORE_ROUND.

In other cases, the manipulation of the floating-point environment is 
needed for correctness, e.g. to avoid spurious exceptions or to implement 
round-to-odd for functions that must be correctly rounding, or it's 
because algorithms for higher internal precision are used (Dekker / Knuth) 
that are only correct in round-to-nearest most and much larger errors 
might occur if those are used in the wrong rounding mode.

-- 
Joseph S. Myers
joseph@codesourcery.com

  reply	other threads:[~2022-08-15 21:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-12 12:28 Wilco Dijkstra
2022-08-15 20:59 ` Joseph Myers [this message]
2022-08-17  4:23   ` Michael Hudson-Doyle
2022-08-17 11:53     ` Wilco Dijkstra
2022-08-17 16:52       ` Joseph Myers
2022-08-22 12:28       ` Paul Zimmermann
  -- strict thread matches above, loose matches on Subject: below --
2022-08-12  0:05 Michael Hudson-Doyle

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=alpine.DEB.2.22.394.2208152055090.311521@digraph.polyomino.org.uk \
    --to=joseph@codesourcery.com \
    --cc=Wilco.Dijkstra@arm.com \
    --cc=libc-alpha@sourceware.org \
    --cc=michael.hudson@canonical.com \
    /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).