From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22709 invoked by alias); 10 Sep 2019 15:23:50 -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 22569 invoked by uid 89); 10 Sep 2019 15:23:50 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=H*i:5ev3fm, H*f:sk:_HA9VeM, H*i:sk:_HA9VeM, H*f:5ev3fm 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; Tue, 10 Sep 2019 15:23:48 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6322630917AC; Tue, 10 Sep 2019 15:23:47 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-3.rdu2.redhat.com [10.10.112.3]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7E9926062D; Tue, 10 Sep 2019 15:23:45 +0000 (UTC) Subject: Re: [PATCH] Simplify sinh (x) / cosh (x) To: Uros Bizjak Cc: Rafael Tsuha , "gcc-patches@gcc.gnu.org" , Mateus Carmo Martins de Freitas Barbosa , Giuliano Augusto Faulin Belinassi References: <710bbc92-6e5a-643f-9a6c-138a74b2e0e7@redhat.com> From: Jeff Law Openpgp: preference=signencrypt Message-ID: <32b9399c-ff54-bbe3-88b1-c0d5f3e5baa5@redhat.com> Date: Tue, 10 Sep 2019 15:23:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg00657.txt.bz2 On 9/10/19 1:36 AM, Uros Bizjak wrote: > On Mon, Sep 9, 2019 at 8:44 PM Jeff Law wrote: >> >> On 9/4/19 12:16 PM, Rafael Tsuha wrote: >>> Hi, Jeff >>> >>> Em seg, 29 de abr de 2019 às 18:22, Jeff Law escreveu: >>>> >>>> On 1/22/19 12:31 PM, Rafael Tsuha wrote: >>>>> This patch simplifies the expression sinh (x) / cosh (x) to tanh (x). >>>>> This rule is mathematically valid. >>>>> >>>>> There's a slight difference in the result when applying this >>>>> optimization with x in the interval 0 < x <= 1e-4951. With the >>>>> optimization, the result using long double is -0 and without the >>>>> optimization, the result is +0. >>>> That's an indication something has gone wrong. >>>> >>>> If I'm reading this correctly it sounds like tanh in that range is >>>> returning -0? If so, that just seems like the wrong output from tanh >>>> since IIUC for a positive input tanh will always have a positive output. >>>> >>> >>> I reverted the patch sent to solve bug 88556 and found out that >>> tanhl(0) started returning -0 after this patch. >>> >>> patch we reverted: >>> (https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/i386/i386.c?r1=267325&r2=267324&pathrev=267325) >>> >>> In the line 44480 of this patch, it checks the sign bit of the input >>> and if it's false the expression is multiplied by -1. In the way it's >>> being calculated, this should be done only if the input is a number >>> greater than zero. >>> >>> If we follow the code starting at line 44468, replacing op1 with 0, we >>> can see that e2 equals 0 at line 44482, flags will be false and >>> finally the e2 = -e2 operation will be executed generating the -0 >>> result. >>> >>> I have implemented a testcase to reproduce the bug: >>> https://paste.debian.net/1098800/ >>> this code was compiled with -Ofast when we tested it. >>> >>> Should I file a bug about this? And for fixing, Is it a good solution >>> to emit an instruction to return zero immediately if the input equals >>> zero? >> So if I'm understanding Uros's patch correctly, it's supposed to only be >> used for -ffast-math where we don't necessarily honor signed zeros. > > True. The full patch is at [1], where it is evident that all these > expanders are protected by flag_unsafe_math_optimizations. As > explained in the patch sumbission, the equations are ported from [2], > so barring some unwanted bug in the porting, they should be equal. I > didn't analyse the correctness of the original equations. It (your patch) looked fine to me given the -ffast-math constraint. I think the question we need to go back and answer is why the proposed patch to improve sinh/cosh -> tanh is using those expanders in an unexpected way. jeff