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 13:05:31 -0400
From: David Edelsohn <dje.gcc@...il.com>
To: musl@...ts.openwall.com
Subject: Re: Musl libm optimizations for Power and Z

On Wed, May 17, 2017 at 12:33 PM, Rich Felker <dalias@...c.org> wrote:
> 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.

The Power and Z ports deserve the same math instruction optimizations
as x86 and ARM.

Thanks, David

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.