From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/595 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: libm Date: Mon, 27 Feb 2012 22:02:53 +0100 Message-ID: <20120227210253.GA25004@port70.net> References: <20120123164152.GZ31975@port70.net> <20120123170715.GA197@brightrain.aerifal.cx> 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: dough.gmane.org 1330376608 14843 80.91.229.3 (27 Feb 2012 21:03:28 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 27 Feb 2012 21:03:28 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-596-gllmg-musl=m.gmane.org@lists.openwall.com Mon Feb 27 22:03:27 2012 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 1S27jC-0005Mb-5J for gllmg-musl@plane.gmane.org; Mon, 27 Feb 2012 22:03:26 +0100 Original-Received: (qmail 26326 invoked by uid 550); 27 Feb 2012 21:03:24 -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 26264 invoked from network); 27 Feb 2012 21:03:05 -0000 Content-Disposition: inline In-Reply-To: <20120123170715.GA197@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:595 Archived-At: * Rich Felker [2012-01-23 12:07:15 -0500]: > On Mon, Jan 23, 2012 at 05:41:52PM +0100, Szabolcs Nagy wrote: > > i've looked into libm implementations > > to figure out what's best for musl > > > the extended precision algorithms are reused across ... > > Any ideas how the different ones evolved (separately written or common > ancestor code, etc.) and where we should look to pull code from? > meanwhile i looked more into libm design issues here are some questions i come up with: for background issues see http://nsz.repo.hu/libm Code organization: (ldX is X bit long double) Do we want ld128? Should we try to use common code for ld80 and ld128? How to do ld64: wrap double functions or alias them? How to tie the ld* code to the arch in the build system? Make complex optional? Keep complex in math/ or cmath/? Workarounds: Use STDC pragmas (eventhough gcc does not support them)? Use volatile consistently to avoid evaluation precision and const folding issues? Use special compiler flags against unwanted optimization (-frounding-math, -ffloat-store)? Do inline/macro optimization for small functions? (isnan, isinf, signbit, creal, cimag,..) In complex code prefer creal(), cimag() or a union to (un)pack re,im? Code cleanups: Keep diffability with freebsd/openbsd code or reformat the code for clarity? Keep e_, s_, k_ fdlibm source file name prefixes? Should 0x1p0 float format be preferred over decimal format? Should isnan, signbit,.. be preferred over inplace bithacks? Is unpacking a double into 2 int32_t ok (signed int representation)? Is unpacking the mantissa of ld80 into an int64_t ok?