Re: [PATCH v3] Add sinh(atanh(x)) and cosh(atanh(x)) optimizations

[Giuliano Augusto Faulin Belinassi <giuliano.belinassi@usp.br>]

Hi,

Sorry, but I am a little confused.

On Wed, Nov 14, 2018 at 11:28 AM Wilco Dijkstra <Wilco.Dijkstra@arm.com> wrote:
>
> Hi,
>
>
> > Indeed. After plotting the graph of both functions, it is very clear
> > that this check isn't required. Sorry about that.
>
> It wouldn't be clear from the graph, you need to check that +0.0, -0.0,
> out of range values, infinities, NaNs give the same answer before/after
> your transformation. If so, then you don't need anything extra except
> for unsafe-math-optimizations and no-math-errno (given errno handling
> is changed).

I checked it. They are all the same on x86_64:
https://pastebin.com/e63FxDAy
I even forced to call the glibc sinh and atanh, but use the sqrtsd instruction.
But I do agree that there may be an arch that sets an errno for sinh
or cosh but not for sqrt, implying in a unexpected behavior.
Is the no-math-errno really necessary?

>
> > There can be NaNs and Infinities. For NaNs, take any input that is
> > outside the [-1, 1] line.
> > For Infinities, take x = -1, or x = 1. I think these must be 'honored'
> > as to ensure compatibility with the original expression.
>
> The question is whether you get the same answer for these, not whether
> you can end up with an infinity or NaN. The idea is that we optimize based
> on the assumption there are no infinities or NaNs. FP operations can still
> produce infinities or NaNs, the compiler just doesn't need to worry about
> treating them correctly, and it's the programmer's reponsibility to ensure
> they are not generated.
>
> > so I must check for
> > !HONOR_SIGNED_ZEROS (type) && HONOR_NANS (type) && HONOR_INFINITIES (type)
> > that is correct? Also, is it safe to remove the !finite_math_only with
> > this, as now it is stated that the type supports infinity and NaNs?
>
> No that doesn't look quite right. First check whether the transformation
> handles zero/inf/NaN correctly, if so you don't need any of this.
>

It does handle these correctly, as far as I am concerned. At least in IEEE 754.
Richard Biener asked to add !flag_siged_zeros for documentation
reasons but this is already covered by unsafe-math. I also checked the
flags from the optimization page, but only unsafe math seems to be
applicable.
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

So maybe just check for unsafe-math?

>
> > However, I am not sure if it is OK to remove unsafe-math-optimizations
> > even if it enables
> > finite_math_only because of the 2 ULP error. As stated in the first
> > iteration, the user can be
> > using a very precise math library that yields 0 ULP.
>
> Well 0 ULP would be an impossibility. Unsafe math seems reasonable since
> it does behave slightly differently (including in terms of exception flags set).
> It's unfortunate GCC doesn't have clear definition of IEEE conformance
> modes like various other compilers.
>
> Wilco
>
>
>