RFC: removing slow paths in various dbl-64 libm functions

[Szabolcs Nagy]

On 01/12/15 04:40, Carlos O'Donell wrote:
> I expect that computations near sharp cuts still require MP solutions to
> attain reasonably accurate answers. What users don't like is that the
> time taken to compute an answer is not constant, and that might even
> constitute a timing oracle in some cases. Either way I think the community

it does not have to be const, only within a reasonable bound.

i think timing oracle is less of a problem than denial of service
on systems with real-time requirements.

(low precision libm cannot solve this completely as the general
bessel functions will take an enormous time depending on the n
argument:

  double yn(int,double);
  int main(){return yn(1e9,1e9);}

will dos gcc when it tries to eval yn at compile-time,
but for other math functions than yn,jn a low time
bound can be guaranteed for all inputs.)

> has consensus that we might try an even lower precision libm with constant
> runtime via the use of -ffast-math to select an alternate libm with no MP
> fallback and higher ULPs. We have discussed this, but have not moved on
> the implementation.

if that happens it should be implemented in such a way
that -ffast-math at link time does not affect the
behaviour of code that was not compiled with -ffast-math.
(i.e. the low prec functions should have different name.)

this is currently a problem with gcc -ffast-math that it
disables subnormal support (flush-to-zero fpu mode) which
affects all fp code in the process (including the c runtime),
which i find too broken to be useful even for -ffast-math.