Math functions and rounding mode

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

Patrick wrote:

> Replaced get_rounding_mode and libc_fesetround() with SET_RESTORE_ROUND
> to avoid Intel rounding mode issue which showed as test failures in
> tgamma_upward. Adds noticable overhead for platforms that incur
> significant cost when rounding mode is already FE_TONEAREST. Added
> SET_RESTORE_ROUND to two more cases which resolved 1 ulp rounding
> errors for cexp().

I don't see how this can be true. SET_RESTORE_ROUND always checks the
rounding mode first and avoids setting it if it is already as expected.
This is true for the generic implementation as well as the Sparc specific
one, so the overhead for both approaches should be identical.

I think we're using the wrong approach here. Assuming exp has acceptable ULP
errors in all rounding modes (we allow a larger ULP in non-nearest modes),
we never need to change rounding mode in exp itself. If functions like tgamma
or cexp end up with errors or unacceptable ULP in non-nearest rounding modes,
we should simply wrap *those* functions with SET_RESTORE_ROUND.

That ensures commonly used math functions have no extra overhead at all.
This should be a key goal given rounding mode changes are expensive on many
targets. If a math function calls multiple basic math functions, you actually
get a speedup as the rounding mode check is done only once.

This means we can concentrate on improving performance of the basic math
functions without spending a large amount of time dealing with non-standard
rounding mode issues in infrequently used math functions.

Does this look like a better way forward?

Wilco