On 13/09/16 12:35, Wilco Dijkstra wrote: > Jakub wrote: >> On Mon, Sep 12, 2016 at 04:19:32PM +0000, Tamar Christina wrote: >>> This patch adds an optimized route to the fpclassify builtin >>> for floating point numbers which are similar to IEEE-754 in format. >>> >>> The goal is to make it faster by: >>> 1. Trying to determine the most common case first >>> (e.g. the float is a Normal number) and then the >>> rest. The amount of code generated at -O2 are >>> about the same +/- 1 instruction, but the code >>> is much better. >>> 2. Using integer operation in the optimized path. >> >> Is it generally preferable to use integer operations for this instead >> of floating point operations? I mean various targets have quite high costs >> of moving data in between the general purpose and floating point register >> file, often it has to go through memory etc. > > It is generally preferable indeed - there was a *very* long discussion about > integer > vs FP on the GLIBC mailing list when I updated math.h to use the GCC builtins > a > while back (the GLIBC implementation used a non-inlined unoptimized integer > implementation, so an inlined FP implementation seemed a good intermediate > solution). > > Integer operations are generally lower latency and enable bit manipulation > tricks like the > fast early exit. The FP version requires execution of 5 branches for a > "normal" FP value > and loads several floating point immediates. There are also many targets with > emulated > floating point types, so 5 calls to the comparison lib function would be > seriously slow. > Note using so many FP comparisons is not just slow but they aren't correct > for signalling > NaNs, so this patch also fixes bug 66462 for fpclassify.
And don't forget that getting the results of a floating-point comparison back to the branch unit may be no faster than transferring the value in the first place. R. > > I would suggest someone with access to a machine with slow FP moves (POWER?) > to benchmark this using the fpclassify test > (glibc/benchtests/bench-math-inlines.c) > so we know for sure. > > Wilco >
