From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104678 invoked by alias); 15 Jun 2016 12:34:26 -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 104661 invoked by uid 89); 15 Jun 2016 12:34:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=Berndt, struggled, berndt, Street X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 15 Jun 2016 12:34:16 +0000 Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u5FCTD6j080333 for ; Wed, 15 Jun 2016 08:34:14 -0400 Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by mx0a-001b2d01.pphosted.com with ESMTP id 23jfmpv7u4-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 15 Jun 2016 08:34:14 -0400 Received: from localhost by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 15 Jun 2016 06:34:13 -0600 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e32.co.us.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 15 Jun 2016 06:34:08 -0600 X-IBM-Helo: d03dlp02.boulder.ibm.com X-IBM-MailFrom: meissner@ibm-tiger.the-meissners.org X-IBM-RcptTo: ian@airs.com;joseph@codesourcery.com;gcc-patches@gcc.gnu.org;dje.gcc@gmail.com;segher@kernel.crashing.org;bschmidt@redhat.com;jakub@redhat.com;jason@redhat.com;law@redhat.com;rth@redhat.com;rguenther@suse.de;wilson@tuliptree.org Received: from b01cxnp22036.gho.pok.ibm.com (b01cxnp22036.gho.pok.ibm.com [9.57.198.26]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 9F6D23E40054; Wed, 15 Jun 2016 06:34:07 -0600 (MDT) Received: from b01ledav006.gho.pok.ibm.com (b01ledav006.gho.pok.ibm.com [9.57.199.111]) by b01cxnp22036.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u5FCY6vf42729676; Wed, 15 Jun 2016 12:34:07 GMT Received: from b01ledav006.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 22D10AC03F; Wed, 15 Jun 2016 08:34:07 -0400 (EDT) Received: from ibm-tiger.the-meissners.org (unknown [9.32.77.111]) by b01ledav006.gho.pok.ibm.com (Postfix) with ESMTP id F1E66AC03A; Wed, 15 Jun 2016 08:34:06 -0400 (EDT) Received: by ibm-tiger.the-meissners.org (Postfix, from userid 500) id 529B64532C; Wed, 15 Jun 2016 08:34:06 -0400 (EDT) Date: Wed, 15 Jun 2016 12:34:00 -0000 From: Michael Meissner To: Richard Biener Cc: Bill Schmidt , Michael Meissner , GCC Patches , Segher Boessenkool , David Edelsohn , Richard Henderson , Jakub Jelinek , Jeff Law , Jason Merrill , Joseph Myers , Bernd Schmidt , Ian Lance Taylor , Jim Wilson Subject: Re: [PATCH] Backport PowerPC complex __float128 compiler support to GCC 6.x Mail-Followup-To: Michael Meissner , Richard Biener , Bill Schmidt , GCC Patches , Segher Boessenkool , David Edelsohn , Richard Henderson , Jakub Jelinek , Jeff Law , Jason Merrill , Joseph Myers , Bernd Schmidt , Ian Lance Taylor , Jim Wilson References: <20160603133335.GA28522@ibm-tiger.the-meissners.org> <20160609200653.GA3361@ibm-tiger.the-meissners.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-12-10) X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16061512-0004-0000-0000-00000FB0520D X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16061512-0005-0000-0000-0000762EA7B2 Message-Id: <20160615123405.GA32375@ibm-tiger.the-meissners.org> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-06-15_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606150137 X-IsSubscribed: yes X-SW-Source: 2016-06/txt/msg01139.txt.bz2 On Wed, Jun 15, 2016 at 11:01:05AM +0200, Richard Biener wrote: > On Tue, 14 Jun 2016, Bill Schmidt wrote: > > > Hi Richard, > > > > As nobody else has replied, let me take a stab at this one. > > > > > On Jun 10, 2016, at 2:06 AM, Richard Biener wrote: > > > > > > On Thu, 9 Jun 2016, Michael Meissner wrote: > > > > > >> I'm including the global reviewers on the list. I just want to be sure that > > >> there is no problem installing these patches on the GCC 6.2 branch. While it > > >> is technically an enchancement, it is needed to be able to install the glibc > > >> support that is needed to complete the work to add IEEE 128-bit floating point. > > >> > > >> The issue being fixed is that when we are creating the complex type, we used to > > >> do a lookup for the size, and that fails on the PowerPC which has 2 128-bit > > >> floating point types (__ibm128 and __float128, with long double currently > > >> defaulting to __ibm128). > > > > > > As this enhancement includes middle-end changes I am hesitant to approve > > > it for the branch. Why is it desirable to backport this change? > > > > It comes down to community requirements and schedules. We are in the process of > > replacing the incompatible IBM long double type with true IEEE-754 128-bit floating > > point (__float128). This is a complex multi-stage process where we will have to > > maintain the functionality of the existing IBM long double for backward compatibility > > while the new type is implemented. This impacts multiple packages, starting with > > gcc and glibc. > > > > The glibc maintainers have indicated that work there depends on a certain level of > > functionality within GCC. Specifically, both the old and new types must be supported, > > including corresponding complex types. Unfortunately the realization that the complex > > types had to be supported came late, and this work didn't fully make it into GCC 6.1. > > > > (Part of the problem that has made this whole effort difficult is that it is complicated to > > maintain two floating-point types of the exact same size.) > > > > In any case, the glibc maintainers require this work in GCC 6 so that work can begin > > in glibc 2.24, with completion scheduled in glibc 2.25. We are asking for an exception > > for this patch in order to allow those schedules to move forward. > > > > So that's the history as I understand it... Perhaps others can jump in if I've munged > > or omitted anything important. > > Ok, I see the reason for the backport then. Looking at the patch > the only fragile thing is the layout_type change give it adds an assert > and you did need to change frontends (but not all of them?). I'm not > sure about testsuite coverage for complex type for, say, Go or Ada > or Java. I added the assert after the review from Berndt. It was to make sure there were no other callers to layout_type to create complex nodes. https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00077.html > And I don't understand the layout_type change either - it looks to me > it could just have used > > SET_TYPE_MODE (type, GET_MODE_COMPLEX_MODE (TYPE_MODE > (TREE_TYPE (type)))); > > and be done with it. To me that looks a lot safer. It has been some time since I looked at the code, I will have to investigate it futher. Note, I will be offline for the next 4 days. > With now having two complex FP modes with the same size how does > iteration over MODE_COMPLEX_FLOAT work with GET_MODE_WIDER_MODE? > Is the outcome random? Or do we visit both modes? That is, could > GET_MODE_COMPLEX_MODE be implemented with iterating over complex modes > and in addition to size also match the component mode instead? I struggled quite a bit with GET_WIDER_MODE. There are three distinct usage cases in the compiler. One case uses GET_WIDER_MODE to initialize all of the types. Here you want to visit all of the types (though we could change the code, since genmode does sort the types so that all of the types for a given class are together). Another case is the normal case, where given a type, go up to a wider type that might implment the code you are looking for. A third case is when generating floating point constants in the constant pool, see if there is a smaller type that maintains the precision. Eventually, I decided to punt having to have explicit paths for widening. I used fractional modes for IFmode (ibm long double format) and KFmode (IEEE 128-bit format). IFmode widens to KFmode which widens to TFmode. A backend hook is used to not allow IBM long double to widen to IEEE long double and vice versa. At the moment, since there is no wider type than 128-bits, it isn't an issue. Note, I do feel the front ends should be modified to allow __complex __float128 directly rather than having to use an attribute to force the complex type (and to use mode(TF) on x86 or mode(KF) on PowerPC). It would clean up both x86 and PowerPC. However, those patches aren't written yet. > [I realize this is just backports but at least the layout_type change > looks dangerous to me] > > Thanks, > Richard. > -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meissner@linux.vnet.ibm.com, phone: +1 (978) 899-4797