From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13852 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH 00/18] math updates Date: Sat, 23 Feb 2019 18:36:02 -0500 Message-ID: <20190223233602.GO23599@brightrain.aerifal.cx> References: <20181208125009.GY21289@port70.net> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="245902"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-13868-gllmg-musl=m.gmane.org@lists.openwall.com Sun Feb 24 00:36:18 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1gxgqA-0011pD-DZ for gllmg-musl@m.gmane.org; Sun, 24 Feb 2019 00:36:18 +0100 Original-Received: (qmail 1387 invoked by uid 550); 23 Feb 2019 23:36:15 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 1362 invoked from network); 23 Feb 2019 23:36:14 -0000 Content-Disposition: inline In-Reply-To: <20181208125009.GY21289@port70.net> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13852 Archived-At: On Sat, Dec 08, 2018 at 01:50:10PM +0100, Szabolcs Nagy wrote: > add new code from > > https://github.com/ARM-software/optimized-routines I think when I merge this, I should include a sha1 hash to indicate what revision it was based on. This documents both code history and license change. There should also be an update to the COPYRIGHT file indicating ARM copyright w/MIT license on new math code. > with small modifications: > - remove all code paths related to errno handling (WANT_ERRNO cases) > - reformat with clang-format to linux style instead of gnu style. > - drop non-default configs (polynomial and table size settings) > - remove SNaN support (but keep the code so adding it back is easy) > - use __FP_FAST_FMA feature test with __builtin_fma I think this should also be conditioned on defined(__GNUC__) or __GNUC__>=something or similar. It's not clear that __FP_FAST_FMA is supposed to imply that. But it looks like it's also used to condition presence of data in headers, so perhaps libm.h should define something indicating whether to use __builtin_fma to put the logic all in one place. > - some macros got renamed: barriers, unlikely, HIDDEN > - kept TOINT_INTRINSICS code paths, but it's never set > (requires __builtin_round and __builtin_lround support as single insn) That's ok. Do you know if it helps enough that we should consider adding these later? > - error handling is split up across several translation units. > - data layout declarations are split into several _data.h headers > > todo: > - fp_barrier implementation for various targets Isn't the only thing that's needed the asm constraint letter for float regs? This would be easier than duplicating the code per-target. What are the exact barrier semantics? Hiding how the output depends on the input from buggy optimizer? Or forcing that the evaluation happen? > - musl does not enable fma contraction, new code would be better with it Yes, we could do it selectively if gcc honored the pragma... > - musl disables fabs etc inlining, using builtins would help Yes. I've thought of trying to make the src/include/*.h patch this up to use the builtins that we can. The problem is not math-specific; string functions (esp memcpy/memset) are an even bigger issue. > - FENV_ACCESS pragma should be set in some top level header in principle > (like features.h) Is there a reason? I like it as documentation of what actually wants it, even if gcc currently isn't honoring it. libm.h might make sense since all of libm needs it. > - use the new helper functions/macros in existing code. > > overall libc.so code size increase on x86_64: +8540 bytes > > (i'll send the patches as attachments in two parts, because they are too > big for one mail) > > Szabolcs Nagy (18): > define FP_FAST_FMA* when fma* can be inlined > math: move complex math out of libm.h > math: add asuint, asuint64, asfloat and asdouble > math: remove sun copyright from libm.h > math: add fp_arch.h with fp_barrier and fp_force_eval > math: add eval_as_float and eval_as_double > math: add single precision error handling functions > math: add double precision error handling functions > math: add macros for static branch prediction hints > math: add configuration macros A few of these things (esp the ones that facilitate broken compilers that don't implement excess-precision right) I'm not really a fan of, or at least don't know if I am (I might be convinced if I'd worked on the code they affect). But as long as they're what work well for you developing and improving this code, and make it easier to share with other projects, I have no objection to going forward with them. Sorry it took a while to get to this. I know sometime last release cycle I said I'd do it in the next cycle, but didn't remember to look back at it right away. The performance figures and code improvements look nice and I definitely want to have this in 1.1.22. Rich