From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3309 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Using float_t and double_t in math functions Date: Thu, 9 May 2013 10:57:14 -0400 Message-ID: <20130509145714.GL20323@brightrain.aerifal.cx> References: <20130509014327.GA6338@brightrain.aerifal.cx> <20130509132157.GF12689@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1368111450 1436 80.91.229.3 (9 May 2013 14:57:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 May 2013 14:57:30 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3313-gllmg-musl=m.gmane.org@lists.openwall.com Thu May 09 16:57:29 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UaSHf-0001sf-M8 for gllmg-musl@plane.gmane.org; Thu, 09 May 2013 16:57:27 +0200 Original-Received: (qmail 10122 invoked by uid 550); 9 May 2013 14:57:27 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 10114 invoked from network); 9 May 2013 14:57:27 -0000 Content-Disposition: inline In-Reply-To: <20130509132157.GF12689@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3309 Archived-At: On Thu, May 09, 2013 at 03:21:57PM +0200, Szabolcs Nagy wrote: > * Rich Felker [2013-05-08 21:43:27 -0400]: > > As far as I can tell, in most of the affected code, keeping excess > > precision does not hurt the accuracy of the result, and it might even > > improve the results. Thus, nsz and I discussed (on IRC) the > > possibility of changing intermediate variables in functions that can > > accept excess precision from float and double to float_t and double_t. > > This would not affect the generated code at all on machines without > > excess precision, but on x86 (without SSE) it eliminates all the > > costly store/load pairs. As an example (on my test machine), it > > ie. it is only for i386 (without sse) > (which is not a trendy platform nowadays) Most distros are still using either i486 or original i686 (no SSE1, much less SSE2) as their x86 target. Of course musl users can opt not to (and compile musl with -mfpmath=sse -msse2) but for universal static binaries a more baseline target may be preferable. > but there it improves performance and > code size a bit so it is worth doing Do you want to do it, or do you want me to? I don't mind but you're more familiar with the code and probably better aware of where it's okay to change. (BTW, it's probably not safe to change arg-reduction code, right?) > at the same time all the STRICT_ASSIGN macros > can be removed (already a noop) which were > there to enforce store with the right precision > on i386 when musl is compiled without -ffloat-store, > but i dont think that should be supported Agreed. I was only vaguely aware they were still around. > btw the other ugly macro that remains is > FORCE_EVAL to force evaluation of floating-point > expressions for their side-effect, which should > be eventually > > #define FORCE_EVAL(expr) do{ \ > _Pragma("STDC FENV_ACCESS ON") \ > expr; \ > } while(0) > > but no compiler supports this that i know of > so now we have volatile hacks with unnecessary > stores I wonder if there's a way to use the result without storing it... Probably not anything sane. Passing to a function would be more costly, I think, and would still be a store on stack-based archs anyway. Rich