This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Simplify sinh (x) / cosh (x)
- From: Jeff Law <law at redhat dot com>
- To: Rafael Tsuha <rafael dot tsuha at usp dot br>
- Cc: gcc-patches at gcc dot gnu dot org, Mateus Carmo Martins de Freitas Barbosa <mateus dot carmo dot barbosa at usp dot br>, Giuliano Augusto Faulin Belinassi <giuliano dot belinassi at usp dot br>, Uros Bizjak <ubizjak at gmail dot com>
- Date: Mon, 9 Sep 2019 12:44:00 -0600
- Subject: Re: [PATCH] Simplify sinh (x) / cosh (x)
- References: <CAHMCd+VFfSGKHOqQwWK7k9+ycA-p8vJU5bLQ2LuRxJ7b+vZX0A@mail.gmail.com> <email@example.com> <CAHMCd+XN9o5PqoBKmCv0i5m1r192WU5PtQD6yptV1cpHxg1bSA@mail.gmail.com>
On 9/4/19 12:16 PM, Rafael Tsuha wrote:
> Hi, Jeff
> Em seg, 29 de abr de 2019 às 18:22, Jeff Law <firstname.lastname@example.org> escreveu:
>> On 1/22/19 12:31 PM, Rafael Tsuha wrote:
>>> This patch simplifies the expression sinh (x) / cosh (x) to tanh (x).
>>> This rule is mathematically valid.
>>> There's a slight difference in the result when applying this
>>> optimization with x in the interval 0 < x <= 1e-4951. With the
>>> optimization, the result using long double is -0 and without the
>>> optimization, the result is +0.
>> That's an indication something has gone wrong.
>> If I'm reading this correctly it sounds like tanh in that range is
>> returning -0? If so, that just seems like the wrong output from tanh
>> since IIUC for a positive input tanh will always have a positive output.
> I reverted the patch sent to solve bug 88556 and found out that
> tanhl(0) started returning -0 after this patch.
> patch we reverted:
> In the line 44480 of this patch, it checks the sign bit of the input
> and if it's false the expression is multiplied by -1. In the way it's
> being calculated, this should be done only if the input is a number
> greater than zero.
> If we follow the code starting at line 44468, replacing op1 with 0, we
> can see that e2 equals 0 at line 44482, flags will be false and
> finally the e2 = -e2 operation will be executed generating the -0
> I have implemented a testcase to reproduce the bug:
> this code was compiled with -Ofast when we tested it.
> Should I file a bug about this? And for fixing, Is it a good solution
> to emit an instruction to return zero immediately if the input equals
So if I'm understanding Uros's patch correctly, it's supposed to only be
used for -ffast-math where we don't necessarily honor signed zeros.
Are you applying the sinh/cosh -> tanh transformation only with
-ffast-math (it's been so long I simply can't remember).