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: Gcc builtin review: isinf, insnan ...


> Joseph Myers wrote:
> On Wed, 27 May 2015, Wilco Dijkstra wrote:
> 
> > Note the GCC built-ins are actually incorrect and should not be used until
> > they are fixed to use integer arithmetic. The GLIBC versions are never
> 
> GCC bug report number?  Is the problem something other than general issues
> with -fsignaling-nans not making everything correct for the presence of
> signaling NaNs (as documented)?  If there are signaling NaN issues but not
> other issues, the built-in functions could be used conditional on
> __SUPPORT_SNAN__ to fix bugs 15367 and 17441, provided (a) comments
> referred to applicable GCC bug reports for any signaling NaN issues, with
> those bug reports referring back to getting the glibc comments updated
> when fixed in GCC, and (b) if uses in glibc rely on proper signaling NaN
> handling, glibc were made to build with -fsignaling-nans (not the default
> in GCC).

Yes I meant the signalling NaN issue. 

> It's certainly the case that substantial GCC work is needed to make
> floating-point properly follow even C99/C11 Annex F regarding exceptions /
> rounding modes, let alone make signaling NaNs follow TS 18661-1, though
> the signaling NaNs fixes would probably be more straightforward (reviewing
> lots of code and making local changes, rather than any tricky design
> issues involved for other floating-point areas).  While I think such
> support would be desirable, it also seems there's limited demand for it.

IMHO support for different rounding modes, trapping exceptions and signalling
NaNs are not required by many (most ARM CPUs don't even support FP traps...), 
so shouldn't be the default. Both GCC and GLIBC are too conservative and don't
generate quality floating point code by default. And despite conservative and 
slow, the produced code is still not good enough to fully support the above 
features, so everybody pays the price of slow code for no useful benefit...

I mostly use -Ofast as that's the only way to get half decent FP code out of GCC. 
GLIBC should also have a mode with fastmath versions of all the math functions.

> 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.

For simple bitmanipulation functions like isinf/isnan etc you can't get anywhere 
near the latency of integer arithmetic on most targets. Note that while FP->int 
moves may be expensive, FP comparisons also move the condition code to the integer
side, and thus have similar latency. If you do multiple isinf and isnan tests on 
the same value (as is common in GLIBC) then the FP->int moves will be CSEd while 
comparisons cannot.

However it would be possible to give targets the option to choose the GCC
builtins if signalling NaNs are disabled - perhaps that might be a way to get
inlining enabled quickly using a simple patch (for the integer versions we'd
need to move the various EXTRACT_WORDS macros into math.h which may be tricky).

Wilco





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