Musl libm optimizations for Power and Z

Musl libm optimizations for Power and Z

[David Edelsohn]

Are there any musl developers who would be interested to work on musl
libm optimizations for Power and Z as financial bounties?

Thanks, David

Re: Musl libm optimizations for Power and Z

[Szabolcs Nagy]

* David Edelsohn <dje.gcc@gmail.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)

Re: Musl libm optimizations for Power and Z

[David Edelsohn]

On Wed, May 17, 2017 at 10:26 AM, Szabolcs Nagy <nsz@port70.net> wrote:
> * David Edelsohn <dje.gcc@gmail.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.

Thanks, David

Re: Musl libm optimizations for Power and Z

[Rich Felker]

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@port70.net> wrote:
> > * David Edelsohn <dje.gcc@gmail.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

Re: Musl libm optimizations for Power and Z

[David Edelsohn]

On Wed, May 17, 2017 at 12:33 PM, Rich Felker <dalias@libc.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@port70.net> wrote:
>> > * David Edelsohn <dje.gcc@gmail.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

Re: Musl libm optimizations for Power and Z

[Rich Felker]

On Wed, May 17, 2017 at 01:05:31PM -0400, David Edelsohn wrote:
> On Wed, May 17, 2017 at 12:33 PM, Rich Felker <dalias@libc.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@port70.net> wrote:
> >> > * David Edelsohn <dje.gcc@gmail.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.

Yes, agreed. My reply was to explain what the rough intent of that
"sameness" is, and the preferred approach going forward (which I want
to eventually move older archs over to as well -- using C files with
asm rather than .s/.S files).

Rich

Re: Musl libm optimizations for Power and Z

[David Edelsohn]

On Wed, May 17, 2017 at 1:17 PM, Rich Felker <dalias@libc.org> wrote:
> On Wed, May 17, 2017 at 01:05:31PM -0400, David Edelsohn wrote:
>> On Wed, May 17, 2017 at 12:33 PM, Rich Felker <dalias@libc.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@port70.net> wrote:
>> >> > * David Edelsohn <dje.gcc@gmail.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.
>
> Yes, agreed. My reply was to explain what the rough intent of that
> "sameness" is, and the preferred approach going forward (which I want
> to eventually move older archs over to as well -- using C files with
> asm rather than .s/.S files).

I had hoped that Bobby Bingham would be interested to work on this,
but I have not heard from him in a while.  Is there anyone else in the
community who would be interested to work on this?

Thanks, David