From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 50388 invoked by alias); 6 Feb 2018 08:55:19 -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 48342 invoked by uid 89); 6 Feb 2018 08:55:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=3.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,KAM_NUMSUBJECT,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=fraction, indication, H*c:alternative X-HELO: aserp2130.oracle.com Received: from aserp2130.oracle.com (HELO aserp2130.oracle.com) (141.146.126.79) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 06 Feb 2018 08:55:02 +0000 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w168qxDT017588; Tue, 6 Feb 2018 08:54:59 GMT Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2130.oracle.com with ESMTP id 2fy8wdgj4w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 06 Feb 2018 08:54:59 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w168swUX008462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 6 Feb 2018 08:54:58 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w168svVP022668; Tue, 6 Feb 2018 08:54:57 GMT Received: from [10.159.139.68] (/10.159.139.68) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Feb 2018 00:54:57 -0800 Subject: Re: [PATCH] PR libgcc/59714 complex division is surprising on aarch64 To: Joseph Myers Cc: gcc-patches@gcc.gnu.org References: <1516912467-13364-1-git-send-email-vladimir.mezentsev@oracle.com> From: vladimir.mezentsev@oracle.com Message-ID: <03c87b52-efb5-3d55-64f3-1d8cad8cb96d@oracle.com> Date: Tue, 06 Feb 2018 08:55:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8796 signatures=668662 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=2 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802060111 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2018-02/txt/msg00212.txt.bz2 On 01/29/2018 12:51 PM, Joseph Myers wrote: > 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.  I compared with __builtin_ilogb. There is a same performance degradation. > 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.  The IEEE format for double is    . We need a function like extract_exponent_field.   All standard function make an additional work to get  exponent. It is a reason why we see performance degradation. % cat r2.c #include int main(int argc, char** argv) {   double d = 0x0.004p-1023;   printf("d=%-24.13a  exp=%d\n", d, __builtin_ilogb(d));   return 0; } % gcc -O2 -lm r2.c ; ./a.out d=0x0.0020000000000p-1022   *exp=-1033 * -Vladimir > 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. >