From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36430 invoked by alias); 22 Oct 2018 20:09:23 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 36390 invoked by uid 89); 22 Oct 2018 20:09:22 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=2.0 required=5.0 tests=BAYES_50,KAM_LAZY_DOMAIN_SECURITY,KAM_LOTSOFHASH,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=H*f:sk:ubJ5Pej, H*f:sk:4CV1P23, HTo:D*br, H*i:CAEFO X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 22 Oct 2018 20:09:21 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 83D9F81DE7; Mon, 22 Oct 2018 20:09:19 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-46.rdu2.redhat.com [10.10.112.46]) by smtp.corp.redhat.com (Postfix) with ESMTP id CE8C260162; Mon, 22 Oct 2018 20:09:16 +0000 (UTC) Subject: Re: [PATCH] Add sinh(tanh(x)) and cosh(tanh(x)) rules To: Giuliano Augusto Faulin Belinassi , Wilco.Dijkstra@arm.com Cc: segher@kernel.crashing.org, GCC Patches , giuliano.belinassi@gmail.com, nd@arm.com References: <20181019134511.GA1712@gate.crashing.org> From: Jeff Law Openpgp: preference=signencrypt Message-ID: <5b717a08-f994-0de8-5092-d11f5d9f8bd0@redhat.com> Date: Mon, 22 Oct 2018 20:58:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-10/txt/msg01359.txt.bz2 On 10/20/18 9:47 AM, Giuliano Augusto Faulin Belinassi wrote: > So I did some further investigation comparing the ULP error. > > With the formula that Wilco Dijkstra provided, there are cases where > the substitution is super precise. > With floats: > with input : = 9.99999940395355224609375000000000000000000000000000e-01 > sinh: before: = 2.89631005859375000000000000000000000000000000000000e+03 > sinh: after : = 2.89630932617187500000000000000000000000000000000000e+03 > sinh: mpfr : = 2.89630924626497842670468162463283783344599446025119e+03 > ulp err befr: = 3 > ulp err aftr: = 0 > > With doubles: > with input : = 9.99999999999999888977697537484345957636833190917969e-01 > sinh: before: = 6.71088640000000298023223876953125000000000000000000e+07 > sinh: after : = 6.71088639999999925494194030761718750000000000000000e+07 > sinh: mpfr : = 6.71088639999999944120645523071287770030292885894208e+07 > ulp err befr: = 3 > ulp err aftr: = 0 > > *However*, there are cases where some error shows up. The biggest ULP > error that I could find was 2. > > With floats: > with input : = 9.99968349933624267578125000000000000000000000000000e-01 > sinh: before: = 1.25686134338378906250000000000000000000000000000000e+02 > sinh: after : = 1.25686149597167968750000000000000000000000000000000e+02 > sinh: mpfr : = 1.25686137592274042266452526368087062890399889097864e+02 > ulp err befr: = 0 > ulp err aftr: = 2 > > With doubles: > with input : = 9.99999999999463651256803586875321343541145324707031e-01 > sinh: before: = 9.65520209507428342476487159729003906250000000000000e+05 > sinh: after : = 9.65520209507428109645843505859375000000000000000000e+05 > sinh: mpfr : = 9.65520209507428288553227922831618987450806468855883e+05 > ulp err befr: = 0 > ulp err aftr: = 2 > > And with FMA we have the same results showed above. (super precise > cases, and maximum ULP error equal 2). > > So maybe update the patch with the following rules? > * If FMA is available, then compute 1 - x*x with it. > * If FMA is not available, then do the dijkstra substitution when |x| > 0.5. So I think the runtime math libraries shoot for .5 ULP (yes, they don't always make it, but that's their goal). We should probably have the same goal. Going from 0 to 2 ULPs would be considered bad. So ideally we'd have some way to distinguish between the cases where we actually improve things (such as in your example). I don't know if that's possible. jeff