[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170517163342.GI17319@brightrain.aerifal.cx>
Date: Wed, 17 May 2017 12:33:42 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Musl libm optimizations for Power and Z
On Wed, May 17, 2017 at 10:52:05AM -0400, David Edelsohn wrote:
> On Wed, May 17, 2017 at 10:26 AM, Szabolcs Nagy <nsz@...t70.net> wrote:
> > * David Edelsohn <dje.gcc@...il.com> [2017-05-17 09:49:22 -0400]:
> >> Are there any musl developers who would be interested to work on musl
> >> libm optimizations for Power and Z as financial bounties?
> >
> > i hope it is something upstreamable
> > (i'm interested in libm optimizations, but cant work for bounties)
>
> I'm not certain what you mean. We want musl libm to include
> optimizations for Power and Z in the musl repository and releases.
Upstreamability could include 2 things: both your/contributor's
willingness to submit the code upstream, and appropriateness of it for
inclusion.
In general we avoid having per-arch math code that's more than simple
fpu instruction wrappers -- math/i386/*.s is about the upper bound on
what I have in mind, as opposed to something like using an entirely
different C algorithm that just happens to be faster on the arch or
that only tangentially uses arch-specific insns. And more importantly,
arch-specific math asm should not be sacrificing correctness/quality
of results for performance or other considerations.
We're also aiming to use inline asm in C files, rather than .s/.S
source files, for new math asm. This allows inlining with LTO, avoids
putting as many calling convention/ABI assumptions in the asm, and
makes it easier to switch off conditionally for soft-float builds (see
src/math/arm/*.c for examples).
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.
