|
Message-ID: <20200109210003.GO23985@port70.net> Date: Thu, 9 Jan 2020 22:00:06 +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 12:00:02 -0500]: > On Thu, Jan 09, 2020 at 06:55:11PM +0300, Alexander Monakov wrote: > > I should have asked earlier, but - is everyone happy with this style of > > expressing removal of excess precision, or should I use eval_as_float? > > > > +{ > > + long double t; > > [...] > > + return (float)t; > > +} > > musl requires C99+ with conforming floating point behavior so I think > this is okay, and I'd prefer to avoid having dependency on libm.h > machinery that's not strictly needed in src/math/$(ARCH) since it > increases the cost of changing that machinery (requires looking at > arch-specific files). My recollection was that eval_as_float is mostly > an artifact of nsz's math functions supporting and being compatible > with somewhat non-conforming compilers. it's an artifact of glibc using -fexcess-precision=fast, so the compiler can do clever transformations (without relying on float_t and double_t), and then they annotate where the excess precision really has to be dropped (using inline asm). i wanted to upstream that code into glibc as well as other math libraries and c99 standard excess precision handling is not the default in most environments (e.g. gcc default -std=gnu* or iso c++) and actually the annotation is rarely needed in math functions: only exact arithmetic tricks need it or at return from public api functions (like in this case) to force a final rounding for side-effects or for sane call abi. so for me it made sense to add explicit annotations which document where this issue is really relevant and allows using the code in more environments by just redefining the eval_as_float etc calls. (on systems where this is relevant results can be different compared to other targets anyway, so allowing more variance depending on different excess-precision settings is not that big deal.) about dropping excess precision at return: c99 required cast at return, but that was considered to be a bug so in c11 it's no longer required: return now must round. of course in non-standard mode return continues to keep excess precision, which seems to require to always annotate returns, but in most math functions all relevant fenv side-effects of the final rounding would need special handling anyway to set errno (assuming you still care about errno: glibc does so my code also cares about it), so overflow etc can't happen in the normal return paths, all such cases are directed to special code that needs special annotations anyway, so return annotation rarely comes up (other than with correctly rounded functions like sqrt). > > If we want to ensure correct rounding (important for sqrt[f]) even on > broken compilers (some ppl use gcc 3.x, and pcc may be broken too?) > perhaps we should just do the store from asm too? that would be a bit safer, but then correct compiler would store twice i think. it's hard to get excited about this issue: it only matters on m68k and i386 which are not the main targets for new float code (and old code had to deal with this and bigger brokenness already). > > 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). btw, i'm not against the cast, but in my optimized-routines code i will keep using my annotations.
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.