[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190223233602.GO23599@brightrain.aerifal.cx>
Date: Sat, 23 Feb 2019 18:36:02 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 00/18] math updates
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
