Re: Math functions and rounding mode

[Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>]

Patrick wrote:

> Perhaps the Sparc specific version is not doing quite the optimal thing. 
> Using the explicit test and get_rounding_mode/libc_fesetround that was in the 
> earlier patch ran much faster on Sparc than SET_RESTORE_ROUND. 
> The Intel version also ran slower with SET_RESTORE_ROUND, but only by
> a few percent.

Maybe it could be improved further, but this shows it's best to avoid messing
about with rounding modes unless there is absolutely no alternative. Even
get_rounding_mode will have a measurable overhead on most targets.

> When the current rounding mode is not FE_TONEAREST on entry to exp(),
> and if we do not change the rounding mode to FE_TONEAREST within exp(),
> then we get more 1 ulp errors according to the make check tests
> of exp(). I suspect users who care enough to try other rounding
> modes than FE_TONEAREST really care about those 1 ulp diffs.

1ULP errors are expected with the new exp implementation as it no longer
does the expensive perfect rounding. So it's not an issue.

cexp currently has a max ULP error of 3 on AArch64 for float, while double
is 1-2. So if this increases by 1 it's not an issue either.

> If performance at the cost of more maintenance overhead were a goal,
> we could supply a complete version of the math library which assumed
> it was always in FE_TONEAREST and never checked/set/restored rounding mode.
> That would also raise the question about which version should be the
> default. I expect that question could generate lots of debate.

That would be a lot of work for no gain. We already have multiple entry points for
many math functions (finite and ieee754) which causes more trouble and overhead
than is worth. We should remove those entry points rather than add even more!

None of the basic math functions require switching of rounding mode as non-nearest
rounding modes don't have unacceptable rounding errors. If we check rounding
mode only in infrequently used (and expensive) math functions then the overhead
will be so small it's not worth worrying about.

Wilco