Hello, Christophe
Could you please dump the assembly of cosatanf here?
On Tue, Oct 16, 2018 at 12:23 PM Christophe Lyon
<christophe.l...@linaro.org> wrote:
>
> On Tue, 16 Oct 2018 at 17:15, Giuliano Augusto Faulin Belinassi
> <giuliano.belina...@usp.br> wrote:
> >
> > Hello. Sorry for the late reply.
> >
> > > 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.
> > Does this behavior is still present if we change the line 58 to:
> > int __attribute__ ((optimize("O0")))
> > in sinatan-1.c?
>
> No, this now generates:
> ldr r0, [fp, #-32]
> bl cosatanf
> where r0=0x5f800000, and cosatanf() returns 0xb33bbd2e
> (ie the same value as what was computed by GCC)
>
> > On Fri, Oct 12, 2018 at 3:24 PM Christophe Lyon
> > <christophe.l...@linaro.org> wrote:
> > >
> > > On Fri, 12 Oct 2018 at 20:01, Giuliano Augusto Faulin Belinassi
> > > <giuliano.belina...@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 <l...@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
