This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH v3] Add sinh(atanh(x)) and cosh(atanh(x)) optimizations
- From: Giuliano Augusto Faulin Belinassi <giuliano dot belinassi at usp dot br>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, ichard dot guenther at gmail dot com, Jeff Law <law at redhat dot com>, Wilco dot Dijkstra at arm dot com
- Date: Wed, 14 Nov 2018 10:58:37 -0200
- Subject: Re: [PATCH v3] Add sinh(atanh(x)) and cosh(atanh(x)) optimizations
- References: <CAEFO=4DeuEG01fxQ=tkATC53MT8SXzsJDfOdCuu2Xv=DPSuGvA@mail.gmail.com> <CAFiYyc0UXqp=h_j6UaK=QW6L-DZzXmZOG_3pwzoB7DWL4qAXLg@mail.gmail.com>
On Wed, Nov 14, 2018 at 7:41 AM Richard Biener
<richard.guenther@gmail.com> wrote:
>
> On Tue, Nov 13, 2018 at 10:25 PM Giuliano Augusto Faulin Belinassi
> <giuliano.belinassi@usp.br> wrote:
> >
> > Only do the optimization if flag_signed_zeros &&
> > !flag_finite_math_only is set, as suggested in the previous iteration.
> >
> > Before, the patch did the optimization even when -fno-signed-zeros and
> > -ffinite-math-only was set. This could generate badly incorrect
> > results for targets that do not support infinite or signed zeros.
>
> How's the result wrong if there are no signed zeros? Note that -ffast-math
> enables -fno-signed-zeros for example. So both of your check look
> backwards.
Indeed. After plotting the graph of both functions, it is very clear
that this check isn't required. Sorry about that.
> Also the support for signed zeros and infs/nans should be guarded with
>
> !HONOR_SIGNED_ZEROS (type) && !HONOR_NANS (type) && !HONOR_INFINITIES (type)
>
> which then means there's no difference between -0. and 0. and there are no
> NaNs or Infs in the inputs and ouptut NaNs or Infs need not be produced.
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.
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?
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.
> Richard.
>
> > I also updated the tests with the proper flags.
> >
> > gcc/ChangeLog
> > 2018-11-13 Giuliano Belinassi <giuliano.belinassi@usp.br>
> >
> > * match.pd (sinh (atanh (x))): New simplification rules.
> > (cosh (atanh (x))): Likewise.
> >
> > gcc/testsuite/ChangeLog
> > 2018-11-13 Giuliano Belinassi <giuliano.belinassi@usp.br>
> >
> > * gcc.dg/sinhatanh-1.c: New test.
> > * gcc.dg/sinhatanh-2.c: New test.
> >
> > There are no tests in trunk that seems to be breaking because of this patch.