Fixing sparc ceil/floor/trunc implementations

[Aurelien Jarno <aurelien at aurel32 dot net>]

Hi,

The ceil, floor and trunc functions on sparc do not fully follow the
standard and trigger an inexact exception when presented a value which
is not an integer. Since glibc 2.24 this causes a few tests to fail,
for instance:

  testing double (without inline functions)
  Failure: ceil (lit_pi): Exception "Inexact" set
  Failure: ceil (-lit_pi): Exception "Inexact" set
  Failure: ceil (min_subnorm_value): Exception "Inexact" set
  Failure: ceil (min_value): Exception "Inexact" set
  Failure: ceil (0.1): Exception "Inexact" set
  Failure: ceil (0.25): Exception "Inexact" set
  Failure: ceil (0.625): Exception "Inexact" set
  Failure: ceil (-min_subnorm_value): Exception "Inexact" set
  Failure: ceil (-min_value): Exception "Inexact" set
  Failure: ceil (-0.1): Exception "Inexact" set
  Failure: ceil (-0.25): Exception "Inexact" set
  Failure: ceil (-0.625): Exception "Inexact" set

I tried to fix that by using the same strategy than used on other
architectures, that is by saving the FSR register at the beginning
and restoring it at the end of the function. When doing so I noticed
a comment that this operation might be very costly, so I decided to
do some benchmarks.

The benchmarks below represent the time required to run each of the
function 60 millions of times with different input value. I have done
that in the basic V9 code, the VIS2 code, and using the default C
implementation of the libc, for both sparc32 and sparc64, on a Niagara
T1 based machine and an UltraSparc IIIi. Given I don't have access to a
more recent machine), I haven't been able to test the VIS3 version. Also
it should be noted that it doesn't make sense to do this benchmark for
V8 or earlier as in that case we use the default C implementation. The
results are available in the table below, the "+ fix" version correspond
to the one saving and restoring the FSR.


  Niagara T1 / sparc32
  --------------------
              ceilf    ceil     floorf   floor    truncf   trunc
  V9          19.10    22.48    19.10    22.48    16.59    19.27
  V9 + fix    19.77    23.34    19.77    23.33    17.27    20.12
  VIS2        16.87    19.62    16.87    19.62
  VIS2 + fix  17.55    20.47    17.55    20.47
  C impl      11.39    13.80    11.40    13.80    10.88    10.84
  
  Niagara T1 / sparc64
  --------------------
              ceilf    ceil     floorf   floor    truncf   trunc
  V9          18.14    22.23    18.14    22.23    15.64    19.02
  V9 + fix    18.82    23.08    18.82    23.08    16.32    19.87
  VIS2        15.92    19.37    15.92    19.37
  VIS2 + fix  16.59    20.22    16.59    20.22
  C impl      11.39    13.60    11.39    15.36    10.88    12.65
  
  UltraSparc IIIi / sparc32
  ------------------------
              ceilf    ceil     floorf   floor    truncf   trunc
  V9           4.81     7.09     6.61    11.64     4.91     7.05
  V9 + fix     7.20    10.42     7.14    10.54     6.76     9.47
  VIS2         4.81     7.03     4.76     7.13
  VIS2 + fix   6.76     9.51     6.71     9.63
  C impl       3.88     8.62     3.90     9.45     3.57     6.62
  
  UltraSparc IIIi / sparc64
  ------------------------
              ceilf    ceil     floorf   floor    truncf   trunc
  V9           3.48     4.39     3.48     4.41     3.01     3.85
  V9 + fix     4.76     5.90     4.76     5.90     4.86     6.26
  VIS2         2.95     3.61     2.95     3.61
  VIS2 + fix   4.24     5.37     4.30     7.97
  C impl       3.63     4.89     3.62     6.38     3.33     4.03


The first thing that should be noted is that the C implementation is
always faster on the Niagara T1 based machine. On the UltraSparc IIIi
the float version on sparc32 is also faster.

Coming back about the fix saving and restoring the FSR, it appears
it has a big impact as expected. In that case the C implementation is
always faster than the fixed implementations.

I would therefore thing that a way to fix the issue without affecting
too much the performances is to remove the sparc specific
implementations. For the sparc64 case where the floating points
arguments are passed through floating point registers, it might make
sense to compile the C implementation using VIS3 to benefit from the
movdtox/movxtod and movwtos/movstow instructions.

Any opinion or comment on that?

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net