From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RDNS_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 16047 invoked from network); 22 Mar 2020 18:51:26 -0000 Received-SPF: pass (mother.openwall.net: domain of lists.openwall.com designates 195.42.179.200 as permitted sender) receiver=inbox.vuxu.org; client-ip=195.42.179.200 envelope-from= Received: from unknown (HELO mother.openwall.net) (195.42.179.200) by inbox.vuxu.org with ESMTP; 22 Mar 2020 18:51:26 -0000 Received: (qmail 25951 invoked by uid 550); 22 Mar 2020 18:51:21 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 25933 invoked from network); 22 Mar 2020 18:51:21 -0000 Date: Sun, 22 Mar 2020 21:51:09 +0300 (MSK) From: Alexander Monakov To: musl@lists.openwall.com In-Reply-To: <20200322175325.GO11469@brightrain.aerifal.cx> Message-ID: References: <20200206145156.GF1663@brightrain.aerifal.cx> <20200222195925.GK1663@brightrain.aerifal.cx> <20200223001942.GM1663@brightrain.aerifal.cx> <20200320181250.GC11469@brightrain.aerifal.cx> <20200322011958.GM11469@brightrain.aerifal.cx> <20200322175325.GO11469@brightrain.aerifal.cx> User-Agent: Alpine 2.20.13 (LNX 116 2015-12-14) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Subject: Re: [musl] 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