This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Gcc builtin review: isinf, insnan ...
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Wilco Dijkstra <wdijkstr at arm dot com>, libc-alpha at sourceware dot org, pinskia at gmail dot com
- Date: Fri, 29 May 2015 13:59:36 +0200
- Subject: Re: Gcc builtin review: isinf, insnan ...
- Authentication-results: sourceware.org; auth=none
- References: <A610E03AD50BFC4D95529A36D37FA55E769AD3FAC3 at GEORGE dot Emea dot Arm dot com> <000e01d0988d$686514d0$392f3e70$ at com> <alpine dot DEB dot 2 dot 10 dot 1505281736460 dot 16930 at digraph dot polyomino dot org dot uk>
On Thu, May 28, 2015 at 05:49:05PM +0000, Joseph Myers wrote:
> On Wed, 27 May 2015, Wilco Dijkstra wrote:
>
> It's not obvious that integer arithmetic is optimal in all cases (if the
> implementation is otherwise correct given the compiler options passed).
> For example, if the argument is in a floating-point register and an
> integer implementation would involve the (architecture-specific) costs of
> moving it to an integer register - obviously something that can only be
> decided quite late in code generation.
>
Naturally one should check which implementation is best. Could you send
link to numeric application and how to measure it that was mentioned
before?
I have bit doubt that floating point would do that well but it needs to
be tested. Versus a cost of moving float to integer register you also
have a cost of loading floating constant which could be as expensive how
do you tell which is faster? Integer computation may even help as due to
pipelining it would be executed in parallel while floating ones would be
sequential.
Also you run into diminishing returns. While you could get lot by using
header a specific optimizations could only rarely save one cycle so are
they worth maintainance burden.