This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] [BZ15384] Enchance finite and isfinite.
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: David Miller <davem at davemloft dot net>
- Cc: marc dot glisse at inria dot fr, libc-alpha at sourceware dot org
- Date: Sat, 27 Apr 2013 03:02:16 +0200
- Subject: Re: [RFC] [BZ15384] Enchance finite and isfinite.
- References: <20130426061732 dot GA6475 at domone dot kolej dot mff dot cuni dot cz> <20130426 dot 030300 dot 673818092125010772 dot davem at davemloft dot net> <20130426084323 dot GA8107 at domone dot kolej dot mff dot cuni dot cz> <20130426 dot 142417 dot 821146595638873920 dot davem at davemloft dot net>
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.
>
> On 32-bit sparc the compiler has to do that anyways in order to pass
> the arguments into finite(), so it will be slightly faster.