Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 17 May 2017 12:33:42 -0400
From: Rich Felker <>
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 <> wrote:
> > * David Edelsohn <> [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

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).


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.