mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Szabolcs Nagy <nsz@port70.net>
To: musl@lists.openwall.com
Subject: Re: [PATCH] math: move i386 sqrtf to C
Date: Fri, 10 Jan 2020 10:17:10 +0100	[thread overview]
Message-ID: <20200110091710.GQ23985@port70.net> (raw)
In-Reply-To: <20200110020747.GY30412@brightrain.aerifal.cx>

* Rich Felker <dalias@libc.org> [2020-01-09 21:07:47 -0500]:
> On Fri, Jan 10, 2020 at 12:18:58AM +0100, Szabolcs Nagy wrote:
> > i think -fexcess-precision=standard was introduced in
> > gcc 4.5 and to get reliable behaviour before that we
> > needed -ffloat-store.
> 
> I don't think the behavior was "reliable" with -ffloat-store; it's
> wrong with respect to the defined meaning of FLT_EVAL_METHOD.

well reliable in the sense that the results are more
consistent with other targets that have FLT_EVAL_METHOD==0.

> > i think we would need to add back the old annotations
> > to make old compilers safe without -ffloat-store.
> > (fdlibm often raises fenv exceptions via a final rounding
> > before return, those could be often handled more cleanly
> > by __math_oflow etc helpers, but since it was not designed
> > for inline errno handling some normal return paths can
> > raise fp exceptions too and thus need eval_as_* annotation).
> 
> I think I asked you before, but from a standpoint of fenv stuff, I'm
> confused why the eval_as_* things are useful at all; it looks like you
> would need fp_barrier* to ensure they're actually evaluated (e.g. in
> the presence of LTO with a compiler that doesn't honor fenv right).

if you mean the current definition of eval_as_* in musl,
then those are not useful (except in the middle of some
arithmetic expression or assignment to double_t etc
where c99 normally would not drop excess precision)

their point is to annotate where we need to drop excess
precision so we can define it appropriately for specific
targets (and allow all other places to use excess prec).

e.g. in case of 'return 0x1p999*0x1p999' to raise overflow
and return inf, we need fp barrier to avoid const folds and
eval_as_double to drop excess precision so it becomes:

  return eval_as_double(fp_barrier(0x1p999) * 0x1p999);

in principle fp_barrier need not drop excess precision so

  return fp_barrier(fp_barrier(0x1p999) * 0x1p999);

would not be enough, but i ended up using float and double
in fp_barrier instead of float_t and double_t so now it
drops excess precision too (may be a mistake, but we almost
always want to drop excess prec when forcing an evaluation).
separate eval_as_double is still useful since on most targets
it is a nop while fp_barrier is not a nop. (but e.g. i386
could define eval_as_double as fp_barrier)

the bigger problem with fp_barrier is that it just hides
a value (behind volatile or asm volatile) but it should be
forcing the mul operation, e.g. currently

  if (cond)
    return eval_as_double(fp_barrier(0x1p999) * 0x1p999);

may be transformed to

  if (cond)
    x = fp_barrier(0x1p999);
  y = x * 0x1p999;
  if (cond)
    return eval_as_double(y);

by a compiler that assumes mul has no side-effects and
then the mul is evaluated unconditionally (but such
transformation is unlikely so in practice the barrier
works).

i don't think there is a trick that allows us to force
the evaluation of an individual fp op, so for now i'm
happy with fp_barrier and eval_as_*.

> 
> But I think it's also useful to distinguish between possibility of
> wrong exceptions being raised, which is a rather minor issue since
> some widely-used compilers don't even support fenv reasonably at at
> all, and the possibility of wrong values being returned for functions
> where the result is required to be correctly rounded. I would deem it
> a serious problem for sqrt[f] or fma[f] to return the wrong value when
> compiled with gcc3 or pcc. I don't think I would particularly care if
> exceptions failed to be raised properly when compiled with gcc3 or
> pcc, though. So I probably would like to ensure that, whatever code we
> end up with in i386 sqrt[f].c, it it ends up working even if the
> compiler does not handle excess precision correctly.

note that rounding down to double to force an overflow
usually also forces an infinity and without the force
the result would be >DBL_MAX finite which then can cause
problems, just like sqrt with excess prec.

so most eval_as_double has the same importance: if any
of them is missed the result may be wrong.

i have fp_force_eval which has no return value and is
only used to force side-effects, if you don't care about
fenv then that may be defined as nop.


  reply	other threads:[~2020-01-10  9:17 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-05 16:35 math patches for moving bare asm to C inline asm Alexander Monakov
2020-01-05 16:36 ` [PATCH] math: move x86_64 fabs, fabsf to C with " Alexander Monakov
2020-01-05 20:05   ` Rich Felker
2020-01-05 21:32     ` Alexander Monakov
2020-01-05 22:43       ` Rich Felker
2020-01-06  8:17         ` Alexander Monakov
2020-01-06  8:40 ` [PATCH] math: move more x86-family fabs functions to C Alexander Monakov
2020-03-21 17:06   ` [musl] " Rich Felker
2020-01-06 16:50 ` [PATCH] math: move trivial x86-family sqrt " Alexander Monakov
2020-01-06 17:43 ` [PATCH] math: move i386 sqrtf " Alexander Monakov
2020-01-06 18:32   ` Pascal Cuoq
2020-01-09 15:55   ` Alexander Monakov
2020-01-09 17:00     ` Rich Felker
2020-01-09 21:00       ` Szabolcs Nagy
2020-01-09 22:00         ` Rich Felker
2020-01-09 23:18           ` Szabolcs Nagy
2020-01-10  2:07             ` Rich Felker
2020-01-10  9:17               ` Szabolcs Nagy [this message]
2020-01-14 17:59         ` [musl] " Alexander Monakov
2020-01-14 18:47           ` Szabolcs Nagy
2020-01-07 13:06 ` [PATCH] math: move i386 sqrt " Alexander Monakov
2020-01-08  7:26   ` Rich Felker
2020-03-21 17:53   ` [musl] " Rich Felker
2020-03-21 17:57     ` Rich Felker
2020-03-21 20:30       ` Alexander Monakov
2020-01-11 15:06 ` [PATCH] math: move x86_64 (l)lrint(f) functions " Alexander Monakov
2020-01-11 15:23 ` [PATCH] math: move more x86-family lrint " Alexander Monakov
2020-01-11 16:07   ` Rich Felker
2020-01-11 16:22     ` Rich Felker
2020-01-14 11:54 ` [musl] [PATCH] math: move x86-family rint " Alexander Monakov
2020-01-14 18:17 ` [musl] Q: dealing with missing removal of excess precision Alexander Monakov
2020-01-14 18:50   ` Szabolcs Nagy
2020-01-14 18:58     ` Rich Felker
2020-01-14 19:53       ` Alexander Monakov
2020-02-06 14:51         ` Rich Felker
2020-02-06 17:15           ` Alexander Monakov
2020-02-06 17:46             ` Rich Felker
2020-02-06 19:03               ` Rich Felker
2020-02-06 20:02                 ` Rich Felker
2020-02-06 22:08                   ` Szabolcs Nagy
2020-02-22 19:59             ` Rich Felker
2020-02-22 20:21               ` Alexander Monakov
2020-02-23  0:19                 ` Rich Felker
2020-02-23 16:14                   ` Alexander Monakov
2020-03-20 18:12                     ` Rich Felker
2020-03-22  1:19                       ` Rich Felker
2020-03-22 17:40                         ` Alexander Monakov
2020-03-22 17:53                           ` Rich Felker
2020-03-22 18:51                             ` Alexander Monakov
2020-03-22 19:10                               ` Rich Felker
2020-03-22 19:46                                 ` Alexander Monakov
2020-01-14 20:41 ` [musl] [PATCH] math: move x86-family remainder functions to C Alexander Monakov
2020-01-15  6:54   ` Szabolcs Nagy
2020-01-15 15:44 ` [musl] [PATCH] math: move x86-family fmod " Alexander Monakov
2020-01-16 21:00 ` [musl] [PATCH] math: add x86_64 remquol Alexander Monakov

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=20200110091710.GQ23985@port70.net \
    --to=nsz@port70.net \
    --cc=musl@lists.openwall.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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

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 NNTP newsgroup(s).