From patchwork Thu Jan 11 18:11:05 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Meissner X-Patchwork-Id: 859228 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-470861-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="oPmAcOlq"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3zHYq2499Kz9s81 for ; Fri, 12 Jan 2018 05:11:25 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:subject:mime-version:content-type:message-id; q=dns; s= default; b=ar6mlTpriRixM6sMqCDRARnFcRqpzYjd1UZ5fSSzvYc2r4wD/6RXg Y/jfR8M6shKItfNFS3iKWUrtB3IRPATLehURa9cn/YTami0FUvV9/4tmaEPQPsRP 65WqMvu9HmZdQYg8jgEwqqe8WTXZDDqGjtcZWDnqThzr1uQsTHjbV0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:subject:mime-version:content-type:message-id; s= default; bh=RR+xWIcVLY/c8LMHljGzrOa48Oo=; b=oPmAcOlqGRPRX+SOfaK7 0f/XYbZjDFVeRcpLvSgCV+0PWv7doeWu39jbKPHoJgAyUj18m79TbxB3g9sQzp+m LyuhTVMxdIlrfXY+jReNuOcXw8j5WJyd2J/Kroy/ZR4QwmIYPfgS4S8h5K0Vv6lc lXlrHCtDZW/u9SKWUYzUIFE= Received: (qmail 8931 invoked by alias); 11 Jan 2018 18:11:17 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 8917 invoked by uid 89); 11 Jan 2018 18:11:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-10.1 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, KAM_ASCII_DIVIDERS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=__ibm128 X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 11 Jan 2018 18:11:15 +0000 Received: from pps.filterd (m0098414.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0BI9vgS112689 for ; Thu, 11 Jan 2018 13:11:13 -0500 Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by mx0b-001b2d01.pphosted.com with ESMTP id 2fecqh0qkr-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 11 Jan 2018 13:11:13 -0500 Received: from localhost by e33.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 11 Jan 2018 11:11:12 -0700 Received: from b03cxnp08028.gho.boulder.ibm.com (9.17.130.20) by e33.co.us.ibm.com (192.168.1.133) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 11 Jan 2018 11:11:10 -0700 Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp08028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w0BIB97H8061302; Thu, 11 Jan 2018 11:11:09 -0700 Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7D88478037; Thu, 11 Jan 2018 11:11:09 -0700 (MST) Received: from ibm-tiger.the-meissners.org (unknown [9.32.77.111]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP id 016B678041; Thu, 11 Jan 2018 11:11:09 -0700 (MST) Received: by ibm-tiger.the-meissners.org (Postfix, from userid 500) id BB2144997A; Thu, 11 Jan 2018 13:11:05 -0500 (EST) Date: Thu, 11 Jan 2018 13:11:05 -0500 From: Michael Meissner To: GCC Patches , Segher Boessenkool , David Edelsohn , Bill Schmidt Subject: [PATCH], Set PowerPC .gnu_attribute for long double use if no call Mail-Followup-To: Michael Meissner , GCC Patches , Segher Boessenkool , David Edelsohn , Bill Schmidt MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-12-10) X-TM-AS-GCONF: 00 x-cbid: 18011118-0008-0000-0000-0000092811AC X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008361; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000245; SDB=6.00973554; UDB=6.00493304; IPR=6.00753499; BA=6.00005773; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00018982; XFM=3.00000015; UTC=2018-01-11 18:11:10 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18011118-0009-0000-0000-000045828E44 Message-Id: <20180111181105.GA20208@ibm-tiger.the-meissners.org> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-11_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1801110247 X-IsSubscribed: yes In working on the transition of PowerPC long double from using the IBM extended double format to IEEE 128-bit floating point, I noticed that the long double .gnu_attribute (#4) was not set if the compiler can handle long double directly without doing the call to an emulator, such as using IEEE 128-bit floating point on an ISA 3.0 (power9) 64-bit system. This patch sets the attribute if there is a move of the appropriate type. I only check TF/TCmode for the normal case, and DF/DCmode for -mlong-double-64, since IFmode is used for __ibm128 when long double is IEEE and KFmode is used for __float128 when long double is IEEE. I have checked this on a little endian power8 system with bootstrap and make check. There were no regressions, and I verified that the three new tests are run and pass. Can I check this into the trunk? [gcc] 2018-01-11 Michael Meissner (rs6000_emit_move): If we load or store a long double type, set the flags for noting the default long double type, even if we don't pass or return a long double type. [gcc/testsuite] 2018-01-11 Michael Meissner * gcc.target/powerpc/gnuattr1.c: New test to make sure we set the appropriate .gnu_attribute for the long double type, if we use the long double type, but do not generate any calls. * gcc.target/powerpc/gnuattr2.c: Likewise. * gcc.target/powerpc/gnuattr3.c: Likewise. Index: gcc/config/rs6000/rs6000.c =================================================================== --- gcc/config/rs6000/rs6000.c (revision 256534) +++ gcc/config/rs6000/rs6000.c (working copy) @@ -10505,6 +10505,22 @@ rs6000_emit_move (rtx dest, rtx source, gcc_unreachable (); } +#ifdef HAVE_AS_GNU_ATTRIBUTE + /* If we use a long double type, set the flags in .gnu_attribute that say + what the long double type is. This is to allow the linker's warning + message for the wrong long double to be useful, even if the function does + not do a call (for example, doing a 128-bit add on power9 if the long + double type is IEEE 128-bit. Do not set this if __ibm128 or __floa128 are + used if they aren't the default long dobule type. */ + if (rs6000_gnu_attr + && ((HAVE_LD_PPC_GNU_ATTR_LONG_DOUBLE || TARGET_64BIT)) + && ((TARGET_LONG_DOUBLE_128 + && (mode == TFmode || mode == TCmode)) + || (!TARGET_LONG_DOUBLE_128 + && (mode == DFmode || mode == DCmode)))) + rs6000_passes_float = rs6000_passes_long_double = true; +#endif + /* See if we need to special case SImode/SFmode SUBREG moves. */ if ((mode == SImode || mode == SFmode) && SUBREG_P (source) && rs6000_emit_move_si_sf_subreg (dest, source, mode)) Index: gcc/testsuite/gcc.target/powerpc/gnuattr1.c =================================================================== --- gcc/testsuite/gcc.target/powerpc/gnuattr1.c (nonexistent) +++ gcc/testsuite/gcc.target/powerpc/gnuattr1.c (working copy) @@ -0,0 +1,15 @@ +/* { dg-do compile { target { powerpc*-linux-* } } } */ +/* { dg-require-effective-target powerpc_vsx_ok } */ +/* { dg-options "-O2 -mvsx -mlong-double-64" } */ +/* { dg-final { scan-assembler "gnu_attribute 4, 9" } } */ + +/* Check that if we can do the long double operation without doing an emulator + call, such as with 64-bit long double support, that we still set the + appropriate .gnu_attribute. */ + +long double a; + +void add1 (void) +{ + a++; +} Index: gcc/testsuite/gcc.target/powerpc/gnuattr2.c =================================================================== --- gcc/testsuite/gcc.target/powerpc/gnuattr2.c (nonexistent) +++ gcc/testsuite/gcc.target/powerpc/gnuattr2.c (working copy) @@ -0,0 +1,17 @@ +/* { dg-do compile { target { powerpc*-linux-* && lp64 } } } */ +/* { dg-require-effective-target powerpc_p9vector_ok } */ +/* { dg-options "-O2 -mpower9-vector -mabi=ieeelongdouble -Wno-psabi" } */ +/* { dg-final { scan-assembler "gnu_attribute 4, 13" } } */ + +/* Check that if we can do the long double operation without doing an emulator + call, such as with IEEE 128-bit hardware support on power9, that we still + set the appropriate .gnu_attribute. The && lp64 is needed, because we can't + enable the IEEE 128-bit hardware instructions on ISA 3.0 (power9) in 32-bit, + because we don't have a TImode available. */ + +long double a; + +void add1 (void) +{ + a++; +} Index: gcc/testsuite/gcc.target/powerpc/gnuattr3.c =================================================================== --- gcc/testsuite/gcc.target/powerpc/gnuattr3.c (nonexistent) +++ gcc/testsuite/gcc.target/powerpc/gnuattr3.c (working copy) @@ -0,0 +1,15 @@ +/* { dg-do compile { target { powerpc*-linux-* } } } */ +/* { dg-require-effective-target powerpc_vsx_ok } */ +/* { dg-options "-O2 -mvsx -mabi=ibmlongdouble -Wno-psabi" } */ +/* { dg-final { scan-assembler "gnu_attribute 4, 5" } } */ + +/* Check that if we can do the long double operation without doing an emulator + call, such as with copysign, that we still set the appropriate + .gnu_attribute. */ + +long double a, b, c; + +void cs (void) +{ + a = __builtin_copysignl (b, c); +}