|
Message-ID: <20200109231858.GP23985@port70.net> Date: Fri, 10 Jan 2020 00:18:58 +0100 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Subject: Re: [PATCH] math: move i386 sqrtf to C * Rich Felker <dalias@...c.org> [2020-01-09 17:00:14 -0500]: > On Thu, Jan 09, 2020 at 10:00:06PM +0100, Szabolcs Nagy wrote: > > > Note that eval_as_float only helps if -ffloat-store is used, which is > > > a nasty hack and also nonconforming, arguably worse than the behavior > > > without it, so we should probably drop use of that as a fallback, and > > > use fp_barrier[f] instead if needed. > > > > i think -ffloat-store almost always drops excess precision > > including returns and assignments, so with that no > > annotation is needed. but yes the way the annotation is > > defined now is not useful against broken compilers or > > non-standard excess precision setting, in glibc the > > annotation is defined differently (with inline asm). > > I was thinking in the context of wanting to remove from configure the: > > || { test "$ARCH" = i386 && tryflag CFLAGS_C99FSE -ffloat-store ; } > > which is probably doing more harm than good. Do you know if there are > things that'd break if we did that? I think eval_as_float should > probably be defined as fp_barrierf to make it safe in your code, > conditional on FLT_EVAL_METHOD>0 (and likewise >1 for eval_as_double). i think -fexcess-precision=standard was introduced in gcc 4.5 and to get reliable behaviour before that we needed -ffloat-store. the freebsd math code had volatile hacks to avoid -ffloat-store but those were incomplete (there were only a few bugs e.g. see commit c4359e01303da2755fe7e8033826b132eb3659b1 freebsd sets x87 precision to double so for them some of these were not issues in practice). since we had -ffloat-store i turned off the volatile hacks in commit 6d3f1a39c14b12026df84f386875b094e3652990 and later completely removed the annotations in commit 9b0fcb441a44456c7b071c7cdaf90403f81ec05a on new compilers -fexcess-precision=standard is used, but that turned out to do too many stores on the fdlibm code (which is why glibc kept using =fast), so in commit e216951f509b71da193da2fc63e25b998740d58b i started using float_t and double_t to get fast code in standard mode. (of course this made things worse for -ffloat-store). 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).
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.