On Fri, 9 Sep 2022, Tobias Burnus wrote: > On 09.09.22 10:10, Andrew Stubbs wrote: > On 08.09.22 22:38, Kwok Cheung Yeung wrote: > The instructions for the transcendental functions are documented to have > limited numerical precision, so they are only used if > unsafe_math_optimizations are enabled for now. > > -funsafe-math-optimizations implies -fno-signed-zeros, -fno-trapping-math, > -fassociative-math, > and -freciprocal-math. All of them reduce precision and my violate IEEE or > ISO/language standards. > > However, I think it is rather surprising to have all of the sudden only a > precision of the > order of 100,000,000 ULP instead of ~4 ULP as to be expected. That's a > precision loss of the > order of 10^8 or 2^29 which is huge! > > For program deliberately using double precision, it can be too much ? even if > they do not need > double precision in reality. (Weather forecast system recently moved to single > precision as the > quality is similar and benefits of faster results/finer grids or longer > forecast times prevail.) > > As this behavior is highly surprising, I think it should be at least > documented. > > In https://gcc.gnu.org/PR105246 , I suggested a new flag (such as > -mpermit-reduced-precision) to > make it possible turn it on/off explicitly (might be still enabled by > -funsafe-math-optimizations); > alternatively, it could also be handled as initial guess for the result which > is then refined > in some iteration steps. (It could also be combined to give the user the > choice.) > > While still being convinced that a flag makes more sense than just documenting > it, > I have nonetheless attached a documentation attempt. > > Thoughts?
I agree - for example powerpc has -mrecip= to control which instructions to use (float/double rsqrt or inverse) and -mrecip-precision to specify whether further iteration is done or not. x86 has similar but does always perform newton raphson iteration, documenting 2 ulp instead of 0.5 ulp precision. Your suggested huge reduction in precision isn't usually acceptable and should be always explicitely enabled. Richard.
