Re: [PATCH] amdgcn: Add support for additional natively supported floating-point operations

[Richard Biener <rguenther@suse.de>]

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.