Re: More patches for math subtree

["Stefan Kanthak" <stefan.kanthak@nexgo.de>]

"Rich Felker" <dalias@libc.org> wrote:

> On Tue, Dec 10, 2019 at 10:32:26PM +0100, Stefan Kanthak wrote:

[ asm vs. C ]

>> Does any compiler emit branch-free instruction sequences like the
>> following for Intel CPUs without SSE4.1, i.e. without ROUNDSS/ROUNDSD?
>> 
>>         .code   ; Intel syntax
>> ceil    proc    public
>>         extern  __real@8000000000000000:real8
>>         movsd   xmm1, __real@8000000000000000
>>         extern  __real@3ff0000000000000:real8
>>         movsd   xmm2, __real@3ff0000000000000
>>         extern  __real@4330000000000000:real8
>>         movsd   xmm3, __real@4330000000000000
>>         movsd   xmm4, xmm1
>>         andnpd  xmm1, xmm0
>>         andpd   xmm4, xmm0
>>         cmpltsd xmm1, xmm3
>>         andpd   xmm1, xmm3
>>         orpd    xmm1, xmm4
>>         movsd   xmm3, xmm0
>>         addsd   xmm0, xmm1
>>         subsd   xmm0, xmm1
>>         movsd   xmm1, xmm0
>>         cmpltsd xmm0, xmm3
>>         andpd   xmm0, xmm2
>>         addsd   xmm0, xmm1
>>         orpd    xmm0, xmm4
>>         ret
>> ceil    endp
>> 
>> Or instruction sequences like
>> 
>>         .code   ; Intel syntax
>> copysign proc   public
>>         movd    rcx, xmm0
>>         movd    rdx, xmm1
>>         shld    rcx, rdx, 1
>>         ror     rcx, 1
>>         movd    xmm0, rcx
>>         ret
>> copysign endp
> 
> Not quite (but it might be possible to write the C in terms of shifts
> instead of masks such that it does), but I also don't think it's clear
> which version is better. Yours here is mildly smaller and might
> perform better, but when making changes that aren't clearly better
> there should be some evidence that it's actually an improvement --
> especially if it's not just improving existing arch optimizations but
> adding new ones where the C was formerly used.

Correct.
I expect the compiler to emit such properly optimised code instead of
calls to the library for standard functions like copysign(), fdim(),
etc. which can be written with just a few instructions ... what the
compiler but not (always) does.

JFTR: I don't know whether GCC or clang either provide intrinsics or
      __builtin_* for such (or all those) small standard functions.

> Generally musl avoids asm and arch-specific files as much as possible,
> using them only for things that aren't representable in C or where
> the C is a lot larger or slower or both.
> 
>>         .code   ; Intel syntax
>> fdim    proc    public
>>         movsd   xmm2, xmm0
>>         cmpsd   xmm0, xmm1, 6
>>         subsd   xmm2, xmm1
>>         andpd   xmm0, xmm2
>>         ret
>> fdim    endp
> 
> Does this handle nans correctly?

Of course! It's equivalent to

double fdim(double a, double b)
{
    uint64_t mask = (a <= b) ? 0ull : ~0ull;
    union {double dbl; uint64_t ull;} u = {a - b};
    u.ull &= mask;
    return u.dbl;
}

[...]

> OK. I don't mind looking at these patches further as-is, and I'll try
> to continue offering constructive comments now, but it'll be after
> this release cycle (hopefully wrapping that up in the next week or so)
> before consideration for merging. musl 1.2.0 is already going to be a
> release with big changes (time64) and I don't want to risk subtle
> breakage with new changes that haven't been reviewed in detail yet or
> had time for users to test.

That's OK.

Stefan