From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 61472 invoked by alias); 7 Nov 2018 22:21:42 -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 61458 invoked by uid 89); 7 Nov 2018 22:21:41 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=BAYES_00,KAM_LOTSOFHASH,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=H*f:sk:2018101, Going 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; Wed, 07 Nov 2018 22:21:40 +0000 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E45F03D953; Wed, 7 Nov 2018 22:21:38 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-54.rdu2.redhat.com [10.10.112.54]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7AF1E4539; Wed, 7 Nov 2018 22:21:36 +0000 (UTC) Subject: Re: [PATCH] Add sinh(tanh(x)) and cosh(tanh(x)) rules To: Richard Biener Cc: Giuliano Augusto Faulin Belinassi , Wilco Dijkstra , Segher Boessenkool , GCC Patches , giuliano.belinassi@gmail.com, nd References: <20181019134511.GA1712@gate.crashing.org> <5b717a08-f994-0de8-5092-d11f5d9f8bd0@redhat.com> From: Jeff Law Openpgp: preference=signencrypt Message-ID: <8ad93f7c-edde-3384-8bde-fb2fa2bd3139@redhat.com> Date: Wed, 07 Nov 2018 22:21: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: 7bit X-IsSubscribed: yes X-SW-Source: 2018-11/txt/msg00494.txt.bz2 On 10/23/18 3:17 AM, Richard Biener wrote: > On Mon, Oct 22, 2018 at 10:09 PM Jeff Law wrote: >> >> 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. > > But we do that everywhere (with -funsafe-math-optimizations or > -fassociative-math). So if we're going from 0->2 ULPs in some cases, do we want to guard it with one of the various options, if so, which? Giuliano's follow-up will still have the potential for 2ULPs. jeff