From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42311 invoked by alias); 29 Jan 2018 20:51:29 -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 41497 invoked by uid 89); 29 Jan 2018 20:51:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=no version=3.3.2 spammy=surprising, wish X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 29 Jan 2018 20:51:27 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=svr-ies-mbx-01.mgc.mentorg.com) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1egGOj-0002wn-MP from joseph_myers@mentor.com ; Mon, 29 Jan 2018 12:51:25 -0800 Received: from digraph.polyomino.org.uk (137.202.0.87) by svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 29 Jan 2018 20:51:22 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.86_2) (envelope-from ) id 1egGOf-0008CP-QY; Mon, 29 Jan 2018 20:51:21 +0000 Date: Mon, 29 Jan 2018 21:01:00 -0000 From: Joseph Myers To: CC: Subject: Re: [PATCH] PR libgcc/59714 complex division is surprising on aarch64 In-Reply-To: Message-ID: References: <1516912467-13364-1-git-send-email-vladimir.mezentsev@oracle.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-SW-Source: 2018-01/txt/msg02281.txt.bz2 On Mon, 29 Jan 2018, vladimir.mezentsev@oracle.com wrote: > > What about powerpc __divkc3? > > > > What was the rationale for using soft-fp rather than adding appropriate > > built-in functions as suggested in a comment? > > I had a version with built-in functions and I can restore it. > > Let's design what we want to use soft-fp or built-in function. > I'd prefer to use built-in functions but performance is in two times worse. > > The test below demonstrates performance degradation: So, this is comparing __builtin_frexp (extracting both exponent and mantissa, including appropriate handling of exponents of subnormal values) with just extracting the exponent and with no special handling of zero / infinity / NaN / subnormal values. We need to consider what functionality is actually needed for this scaling, if we do wish to use such scaling based on integer exponents. If what's needed corresponds exactly to some standard functions such as ilogb and scalbn with all their special cases, then built-in versions of those standard functions may make sense. If what's needed does not correspond to standard functions and does not need to handle such special cases, that's more of an indication for examining the representation in libgcc - but it's still necessary to handle the many different variant floating-point formats supported, or to safely avoid using the new code for formats it can't handle. -- Joseph S. Myers joseph@codesourcery.com