Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 11 Dec 2019 10:53:41 +0100
From: "Stefan Kanthak" <>
To: "Rich Felker" <>
Cc: <>
Subject: Re: More patches for math subtree

"Rich Felker" <> 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@...0000000000000:real8
>>         movsd   xmm1, __real@...0000000000000
>>         extern  __real@...0000000000000:real8
>>         movsd   xmm2, __real@...0000000000000
>>         extern  __real@...0000000000000:real8
>>         movsd   xmm3, __real@...0000000000000
>>         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.

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.


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.