This is the mail archive of the
`gcc-patches@gcc.gnu.org`
mailing list for the GCC project.

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |

Other format: | [Raw text] |

*From*: Giuliano Augusto Faulin Belinassi <giuliano dot belinassi at usp dot br>*To*: Jeff Law <law at redhat dot com>*Cc*: Richard Biener <richard dot guenther at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>*Date*: Thu, 23 Aug 2018 08:20:59 -0300*Subject*: Re: patch to bug #86829*References*: <CAEFO=4AiqFvHH5sb1xWguEoSY2osH+NZJzWELkHqefEbgTd_6g@mail.gmail.com> <5c2ff99f-f23a-97d6-4bbe-a1cc20e649fa@redhat.com> <CAFiYyc32AagkKsYfA-EvPOWEr3oryDu0GmfDvBybSHUsLeaSbA@mail.gmail.com> <5036aefe-ad98-15c4-51cd-b3122d38faec@redhat.com> <CAEFO=4DXCrkAgSNOKupZKOQTmMd_XjdPvZYG4UTja6Bv=heXcQ@mail.gmail.com> <1c11bb3b-f06a-fe7d-2186-0eb5be203b38@redhat.com> <CAFiYyc0oyY=gxd0E=SkqOnk2=RZwMKq-ZjcBODfVKQfwyY-SBA@mail.gmail.com> <8f397330-a628-56cd-05e2-c07ee55571ba@redhat.com>

> > Ah, a runtime test. That'd be sufficient. The cost when we can't do > the transformation is relatively small, but the gains when we can are huge. Thank you. I will update the patch and send it again :-) On Wed, Aug 22, 2018 at 7:05 PM, Jeff Law <law@redhat.com> wrote: > On 08/22/2018 06:02 AM, Richard Biener wrote: >> On Tue, Aug 21, 2018 at 11:27 PM Jeff Law <law@redhat.com> wrote: >>> >>> On 08/21/2018 02:08 PM, Giuliano Augusto Faulin Belinassi wrote: >>>>> Just as an example, compare the results for >>>>> x = 0x1.fffffffffffffp1023 >>>> >>>> Thank you for your answer and the counterexample. :-) >>>> >>>>> If we had useful range info on floats we might conditionalize such >>>>> transforms appropriately. Or we can enable it on floats and do >>>>> the sqrt (x*x + 1) in double. >>>> >>>> I think I managed to find a bound were the transformation can be done >>>> without overflow harm, however I don't know about rounding problems, >>>> however >>>> >>>> Suppose we are handling double precision floats for now. The function >>>> x/sqrt(1 + x*x) approaches 1 when x is big enough. How big must be x >>>> for the function be 1? >>>> >>>> Since sqrt(1 + x*x) > x when x > 1, then we must find a value to x >>>> that x/sqrt(1 + x*x) < eps, where eps is the biggest double smaller >>>> than 1. Such eps must be around 1 - 2^-53 in ieee double because the >>>> mantissa has 52 bits. Solving for x yields that x must be somewhat >>>> bigger than 6.7e7, so let's take 1e8. Therefore if abs(x) > 1e8, it is >>>> enough to return copysign(1, x). Notice that this arguments is also >>>> valid for x = +-inf (if target supports that) because sin(atan(+-inf)) >>>> = +-1, and it can be extended to other floating point formats.The >>>> following test code illustrates my point: >>>> https://pastebin.com/M4G4neLQ >>>> >>>> This might still be faster than calculating sin(atan(x)) explicitly. >>>> >>>> Please let me know if this is unfeasible. :-) >>> The problem is our VRP implementation doesn't handle any floating point >>> types at this time. If we had range information for FP types, then >>> this kind of analysis is precisely what we'd need to do the >>> transformation regardless of -ffast-math. >> >> I think his idea was to emit a runtime test? You'd have to use a >> COND_EXPR and evaluate both arms at the same time because >> match.pd doesn't allow you to create control flow. >> >> Note the rounding issue is also real given for large x you strip >> away lower mantissa bits when computing x*x. > Ah, a runtime test. That'd be sufficient. The cost when we can't do > the transformation is relatively small, but the gains when we can are huge. > > Jeff

**References**:**patch to bug #86829***From:*Giuliano Augusto Faulin Belinassi

**Re: patch to bug #86829***From:*Jeff Law

**Re: patch to bug #86829***From:*Richard Biener

**Re: patch to bug #86829***From:*Jeff Law

**Re: patch to bug #86829***From:*Giuliano Augusto Faulin Belinassi

**Re: patch to bug #86829***From:*Jeff Law

**Re: patch to bug #86829***From:*Richard Biener

**Re: patch to bug #86829***From:*Jeff Law

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |