|
Message-ID: <alpine.LNX.2.20.13.2003222136510.2534@monopod.intra.ispras.ru> Date: Sun, 22 Mar 2020 21:51:09 +0300 (MSK) From: Alexander Monakov <amonakov@...ras.ru> To: musl@...ts.openwall.com Subject: Re: Q: dealing with missing removal of excess precision On Sun, 22 Mar 2020, Rich Felker wrote: > > Nack for sqrt 'unsigned short' fix, I recommend to consider > > 'unsigned fpsr = 0' and "+a" constraint, the resulting assembly is > > much better (GCC doesn't seem to do a good job optimizing the 'unsigned short' > > variant at all). > > Sorry, I forgot to disassemble and check after making that change, and > indeed it is very bad. > > How about just leaving it as-is? The value is masked such that upper > bits don't matter, and "whatever the register happened to contain > before" is a valid albeit ugly output from inline asm -- it doesn't > admit any compiler transformations that would cause inconsistent value > to be observed or other problems. Yes, I guess it's acceptable. > > Actually, may I ask why the initial commit did not mention that it relies > > on this nontrivial property? > > The need for fixup of double was only realized later, in commit > 809556e60a3359f646946879dd94c4760e5b8e84. It was discussed at the time > that no action was needed for single, but it seems since there was no > change there wasn't any mention of it in log. Are you sure? single-precision sqrtf received a change just two days prior to that in commit e0a54e6725 ("correct rounding for i387 sqrtf function") which is the same day as when Stephen Canon supplied his answer in https://stackoverflow.com/questions/9678224/is-there-any-way-to-get-correct-rounding-with-the-i387-fsqrt-instruction (and also the same day you asked the question) Alexander
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.