This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] [BZ15384] Enchance finite and isfinite.


From: Ondřej Bílka <neleai@seznam.cz>
Date: Sat, 27 Apr 2013 03:02:16 +0200

> On Fri, Apr 26, 2013 at 02:24:17PM -0400, David Miller wrote:
>> From: Ondřej Bílka <neleai@seznam.cz>
>> Date: Fri, 26 Apr 2013 10:43:23 +0200
>> 
>> > On Fri, Apr 26, 2013 at 03:03:00AM -0400, David Miller wrote:
>> >> From: Ondřej Bílka <neleai@seznam.cz>
>> >> Date: Fri, 26 Apr 2013 08:17:32 +0200
>> >> 
>> >> > Following should generic version be tried on other archs. I could get
>> >> > 20% speedup on sparc on this benchmark. 
>> >> > 
>> >> > run with
>> >> > for i in `seq 0 7`; do echo finite$i;  gcc finite_bench.c -O3 -Wall -W -fno-builtin-finite -Dfinite=finite$i; for j in `seq 1 8`; do /usr/bin/time -f "%U" ./a.out; done; done
>> >> 
>> >> That'll only be faster on sparc 32-bit where floating point
>> >> values are passed in integer registers.
>> >> 
>> >> For 64-bit, where floating point values are passed in floating point
>> >> registers, the assembler in glibc will always be faster because GCC
>> >> isn't smart enough to avoid allocating a register window when a stack
>> >> slot is needed to move values between float and integer registers.
>> > 
>> > My benchmark tries to measure speed of inlined version when used in
>> > condition. As 99% of uses are in condition this looks reasonable. Idealy
>> > gcc should simplify condition based on expansion and have it smaller
>> > than function call. 
>> 
>> This inline variant will be slower than the function call on 64-bit
>> sparc, because popping the value through the stack will force the
>> function to not be a leaf function and therefore allocate a register
>> window.
> 
> I am sure if I understand. When I write 
> #define finite(x) (((CONVERT(x)>>52)&0x7ff)==0x7ff)
> will still this point apply? This is what I meant by inlining.

It depends.

If glibc is going to use the multiarch variant that uses the float-int
move instructions, calling finite() will be faster on 64-bit if gcc
isn't using those instructions (which is %99 certainly the case).

Generally, if there are multiarch variants of a libm function it should
be used rather than an inline.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]