Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.