[PATCH] Optimize sin(atan(x)) and cos(atan(x)), take 3 (PR tree-optimization/86829)

[Christophe Lyon]

On Fri, 12 Oct 2018 at 20:01, Giuliano Augusto Faulin Belinassi
<giuliano.belinassi@usp.br> wrote:
>
> > fc is built with:
> >        mov     r0, #0
> >        movt    r0, 24448
> > so r0=0x5f800000 (1.8446744E19) which looks ok
>
> this is correct. My x86_64 yields the same value
>
> > but then cosatanf is computed as (ie there's not call to cosatanf()):
> >        movw    r3, #48430
> >        movt    r3, 45883
> > so r3=0xb33bbd2e (-4.371139E-8) which is not zero.
>
> Ugh. So GCC replaced the function call with a precomputed value? This
> does not happens in my x86_64. Maybe it is Ofast's fault?
> Also, it seems that GCC is precomputing cos(atan(x)) before the
> substitution, as the following python script yields the same result:
>

Yes, I was surprised to see that.

> import numpy as np
> x = np.float32 (1.8446744e19)
> print (np.cos (np.arctan (x))
>
> I would also like to add that -4.371139E-8 is very far away from
> 5.421011E-20, which is a "more" correct value for this computation. So
> returning 0 may be a better option?
> On Fri, Oct 12, 2018 at 12:57 PM Jeff Law <law@redhat.com> wrote:
> >
> > On 10/12/18 9:51 AM, Giuliano Augusto Faulin Belinassi wrote:
> > > Hello
> > >      What is the output of these functions on such arch? Since the
> > > test didn't fail for the sinatan counterpart, an possible explanation
> > > would be that the calculation of the sqrf, sqrt and sqrtl (lines
> > > 62-64) yielded a number that is far behind of what it should be.
> > > However, I am still not sure about this, so I will investigate
> > > further.
> > >      How about I  write a small program to check if the result
> > > obtained by this calculation is what it should be?
> > I suspect it's less the architecture and more the underlying library.
> > As Christophe mentioned, both issues are with newlib which is an C
> > library primarily used in the emebedded space.  I believe it's math code
> > derives from early BSD libm and likely hasn't been stressed for this
> > kind of correctness.  It's lightly maintained (primarily for cygwin).
> >
> > I'm going to run the testcases in my arm linux chroots.  That should
> > allow us to rule out codegen issues as those chroots will be using glibc
> > for their math library.
> >
> > jeff