This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Add simplification rule tanh (x) * cosh (x) -> sinh (x)
- From: Giuliano Belinassi <giuliano dot belinassi at usp dot br>
- To: Jeff Law <law at redhat dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, Prathamesh Kulkarni <prathamesh dot kulkarni at linaro dot org>, Bárbara de Castro Fernandes <barbara dot fernandes at usp dot br>, gcc Patches <gcc-patches at gcc dot gnu dot org>
- Date: Sat, 4 May 2019 21:21:15 -0300
- Subject: Re: [PATCH] Add simplification rule tanh (x) * cosh (x) -> sinh (x)
- References: <CAJ+V80pmKV82VuHAzBXGow2_ZZGQY8XRkF-FVGEOpNSb3tYH9Q@mail.gmail.com> <b0cd623f-bbba-37aa-9a5c-f95fa1ca1211@redhat.com> <CAAgBjMn13OwywogqUffizA0x0TrnbpH0aCdruOZNt72qQBg96A@mail.gmail.com> <0e3fc634-8785-8853-b55c-ac2156955be9@redhat.com> <20190430140018.GI2706@tucnak> <bb57d5ed-dc32-2291-e38e-ca360130f8d7@redhat.com>
Hi
On 04/30, Jeff Law wrote:
> On 4/30/19 8:00 AM, Jakub Jelinek wrote:
> > On Tue, Apr 30, 2019 at 07:57:20AM -0600, Jeff Law wrote:
> >>> Just curious, do we want to add math identities like above to match.pd ?
> >> I'd think so.
> >>
> >>
> >>> In practice, I am not sure how often we'd see "tanh * cosh" instead
> >>> of sinh directly in source,
> >> We're often surprised when what ultimately shows up in sources :-) And
> >> a transformation that allows us to turn two transcendentals and a
> >> multiplication into a single transcendental is going to be a big win.
> >
I wonder why these kind of optimization are not in the EasyHacks page.
It is somewhat easy to add it and can give huge performance
improvements.
There is a blogpost that I wrote about the previous patches I submitted
here. I tried to be didadic, discussing from the mathematical
standpoint, to floating point numbers, and GCC implementation.
Although there may be several english errors, I think it is still
useful:
https://flusp.ime.usp.br/gcc/2019/03/26/making-gcc-optimize-some-trigonometric-functions/
> > I guess an important question is if such transformations need to be guarded
> > by some -ffast-math suboptions, whether those transformations work properly
> > for signed zeros, NaNs, sNaNs, infinities, guarantee the same ulp, have the
> > same -ferrno-math behavior etc.
> Yes. If you look at the discussion with Gualiano for the first set in
> this space that was the hardest part. And for Barbara's we know there's
> at least one issue in this space as well -- in particular it looks like
> the long double handling is incorrect in the sign bit for very small
> inputs. The question is precisely where that's gone wrong :-)
>
> jeff
Giuliano.