|
Message-ID: <F2BD74F09B4748A094E99A4B8C5CBB4A@H270> Date: Wed, 11 Dec 2019 10:53:41 +0100 From: "Stefan Kanthak" <stefan.kanthak@...go.de> To: "Rich Felker" <dalias@...c.org> Cc: <musl@...ts.openwall.com> Subject: Re: More patches for math subtree "Rich Felker" <dalias@...c.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@...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. 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
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.