From patchwork Mon May 2 21:10:24 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Meissner X-Patchwork-Id: 617705 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org 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 3qzH5r6fWpz9t5W for ; Tue, 3 May 2016 07:10:55 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=roZ8+nig; dkim-atps=neutral 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:cc:subject:message-id:references:mime-version :content-type:in-reply-to; q=dns; s=default; b=BV6dpfZCUwc93z1wK MiUZ6Wdmsn/0NdjUjAuzy00LlznQvBkb8/vfnGK7wvj44Eg3H0KhV1NaftUT3y4K SKun9sl/xau3FhtRvr77Y3r+jRCLTQtb6vwd+EtZ4e7RKZGcl6HfZ2upMnSjjbHE gVsqa7j978OZFpwp6GY9i1103k= 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:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=default; bh=lg726T5xSqNOkOL0MNy9tN7 hrZY=; b=roZ8+nig8aYDggQkRwwdXDCTWCv4YACALo+d0vEG4o4jZblo82NlVko rqTduiiwbwlbV6RJgnzHE0lMa/rULiOaC1K7KNPQAvU5EwweRlBYzBuT280HDJWo Nb5pI9yPkMiB7PRE304c4nkzacfIfxsKhj30C+t9Fii77QuO0BQg= Received: (qmail 16313 invoked by alias); 2 May 2016 21:10:40 -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 16294 invoked by uid 89); 2 May 2016 21:10:39 -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_50, KAM_ASCII_DIVIDERS, KAM_LAZY_DOMAIN_SECURITY, KAM_MANYTO autolearn=no version=3.3.2 spammy=King, HTo:U*tkoenig, settle, HTo:U*jb X-HELO: e18.ny.us.ibm.com Received: from e18.ny.us.ibm.com (HELO e18.ny.us.ibm.com) (129.33.205.208) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Mon, 02 May 2016 21:10:34 +0000 Received: from localhost by e18.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 2 May 2016 17:10:32 -0400 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e18.ny.us.ibm.com (146.89.104.205) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 2 May 2016 17:10:28 -0400 X-IBM-Helo: d01dlp02.pok.ibm.com X-IBM-MailFrom: meissner@ibm-tiger.the-meissners.org X-IBM-RcptTo: d@domob.eu; fxcoudert@gcc.gnu.org; gcc-patches@gcc.gnu.org; janus@gcc.gnu.org; jb@gcc.gnu.org; jvdelisle@gcc.gnu.org; pault@gcc.gnu.org; tkoenig@gcc.gnu.org; dje.gcc@gmail.com; franke.daniel@gmail.com; erik.edelmann@iki.fi; segher@kernel.crashing.org; toon@moene.org; burnus@net-b.de; tobias.schlueter@physik.uni-muenchen.de; bschmidt@redhat.com; mikael.morin@sfr.fr Received: from b01cxnp23033.gho.pok.ibm.com (b01cxnp23033.gho.pok.ibm.com [9.57.198.28]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 985DA6E8040; Mon, 2 May 2016 17:10:12 -0400 (EDT) Received: from b01ledav002.gho.pok.ibm.com (b01ledav002.gho.pok.ibm.com [9.57.199.107]) by b01cxnp23033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u42LASL442270938; Mon, 2 May 2016 21:10:28 GMT Received: from b01ledav002.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E3540124037; Mon, 2 May 2016 17:10:27 -0400 (EDT) Received: from ibm-tiger.the-meissners.org (unknown [9.32.77.111]) by b01ledav002.gho.pok.ibm.com (Postfix) with ESMTP id C2C44124035; Mon, 2 May 2016 17:10:27 -0400 (EDT) Received: by ibm-tiger.the-meissners.org (Postfix, from userid 500) id 83B6845EAA; Mon, 2 May 2016 17:10:26 -0400 (EDT) Date: Mon, 2 May 2016 17:10:24 -0400 From: Michael Meissner To: Bernd Schmidt , Janne Blomqvist , Tobias Burnus , "FranC'ois-Xavier Coudert" , Jerry DeLisle , Erik Edelmann , Daniel Franke , Thomas KC6nig , Daniel Kraft , Toon Moene , Mikael Morin , tobias.schlueter@physik.uni-muenchen.de, Paul Thomas , Janus Weil Cc: Segher Boessenkool , Michael Meissner , gcc-patches@gcc.gnu.org, David Edelsohn , Bill Schmidt Subject: Re: [PATCH #3], Fix _Complex when there are multiple FP types the same size Message-ID: <20160502211024.GA17046@ibm-tiger.the-meissners.org> Mail-Followup-To: Michael Meissner , Bernd Schmidt , Janne Blomqvist , Tobias Burnus , FranC'ois-Xavier Coudert , Jerry DeLisle , Erik Edelmann , Daniel Franke , Thomas KC6nig , Daniel Kraft , Toon Moene , Mikael Morin , tobias.schlueter@physik.uni-muenchen.de, Paul Thomas , Janus Weil , Segher Boessenkool , gcc-patches@gcc.gnu.org, David Edelsohn , Bill Schmidt References: <20160428210613.GA29745@ibm-tiger.the-meissners.org> <20160428221006.GC6575@gate.crashing.org> <20160428234057.GA20519@ibm-tiger.the-meissners.org> <20160429205127.GA19596@ibm-tiger.the-meissners.org> <20160430160045.GA15163@gate.crashing.org> <572731F3.2060104@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <572731F3.2060104@redhat.com> User-Agent: Mutt/1.5.20 (2009-12-10) X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16050221-0045-0000-0000-00000415A85B X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused X-IsSubscribed: yes On Mon, May 02, 2016 at 12:54:43PM +0200, Bernd Schmidt wrote: > On 04/30/2016 06:00 PM, Segher Boessenkool wrote: > >On Fri, Apr 29, 2016 at 04:51:27PM -0400, Michael Meissner wrote: > >>2016-04-29 Michael Meissner > >> > >> * config/rs6000/rs6000.c (rs6000_hard_regno_nregs_internal): Add > >> support for __float128 complex datatypes. > >> (rs6000_hard_regno_mode_ok): Likewise. > >> (rs6000_setup_reg_addr_masks): Likewise. > >> (rs6000_complex_function_value): Likewise. > >> * config/rs6000/rs6000.h (FLOAT128_IEEE_P): Likewise. > >> __float128 and __ibm128 complex. > >> (FLOAT128_IBM_P): Likewise. > >> (ALTIVEC_ARG_MAX_RETURN): Likewise. > >> * doc/extend.texi (Additional Floating Types): Document that > >> -mfloat128 must be used to enable __float128. Document complex > >> __float128 and __ibm128 support. > >> > >>[gcc/testsuite] > >>2016-04-29 Michael Meissner > >> > >> * gcc.target/powerpc/float128-complex-1.c: New tests for complex > >> __float128. > >> * gcc.target/powerpc/float128-complex-2.c: Likewise. > > > >The powerpc parts are okay for trunk. Thank you! > > Ok for the other parts as well. Although I wonder: > > >+ /* build_complex_type has set the expected mode to allow having multiple > >+ complex types for multiple floating point types that have the same > >+ size such as the PowerPC with __ibm128 and __float128. If this was > >+ not set, figure out the mode manually. */ > >+ if (TYPE_MODE (type) == VOIDmode) > >+ { > >+ unsigned int precision = TYPE_PRECISION (TREE_TYPE (type)); > >+ enum mode_class mclass = (TREE_CODE (TREE_TYPE (type)) == REAL_TYPE > >+ ? MODE_COMPLEX_FLOAT : MODE_COMPLEX_INT); > >+ SET_TYPE_MODE (type, mode_for_size (2 * precision, mclass, 0)); > >+ } > > What happens if you assert that it isn't VOIDmode? On the PowerPC, I did a full boostrap with the code changed to a gcc_assert, and it didn't trigger. However, in looking at it further, there are only two places that layout_type is called after making a complex node. The first is build_complex_type that I provided a patch for. The other is a similar function in the Fortran front end (gfc_build_complex_type). Now, assuming you only use the 3 standard floating point modes (float_type_node, double_type_node, and long_double_type_node) you wouldn't notice any problem. But if somehow Fortran can create a __float128 type, it would trigger the assertion (in the new patches) or generate the wrong type (in the previous patches). So I would like to commit the following changes (assuming they bootstrap and have no regressions) instead. Are these patches ok for the trunk, and eventually the gcc 6.2 branch if they don't break other back ends? Fortran people, I'm adding you to the To: list, because of the Fortran change. What the problem is the current layout_type uses 2*size of the base type to create the complex type. However, in the current PowerPC, we are transitioning from using IBM extended double format (pair of doubles to give more mantissa bits, but no extra exponent range) to IEEE 128-bit format, and we have two 128-bit complex types. You get all sorts of errors if you want to use the REAL or IMAGINARY parts and you get the wrong type. The patch builds a table that maps a given base mode to the complex mode that uses the base mode as the two elements (i.e. GET_MODE_COMPLEX_MODE (DFmode) would return DCmode. The machine independent changes are in the gcc-stage7.patch003b, and the PowerPC specific changes are in gcc-stage7.patch003c. [gcc] 2016-05-02 Michael Meissner * machmode.h (mode_complex): Add support to give the complex mode for a given mode. (GET_MODE_COMPLEX_MODE): Likewise. * stor-layout.c (layout_type): For COMPLEX_TYPE, use the mode stored by build_complex_type and gfc_build_complex_type instead of trying to figure out the appropriate mode based on the size. Raise an assertion error, if the type was not set. * genmodes.c (struct mode_data): Add field for the complex type of the given type. (blank_mode): Likewise. (make_complex_modes): Remember the complex mode created in the base type. (emit_mode_complex): Write out the mode_complex array to map a type mode to the complex version. (emit_insn_modes_c): Likewise. * tree.c (build_complex_type): Set the complex type to use before calling layout_type. * config/rs6000/rs6000.c (rs6000_hard_regno_nregs_internal): Add support for __float128 complex datatypes. (rs6000_hard_regno_mode_ok): Likewise. (rs6000_setup_reg_addr_masks): Likewise. (rs6000_complex_function_value): Likewise. * config/rs6000/rs6000.h (FLOAT128_IEEE_P): Likewise. __float128 and __ibm128 complex. (FLOAT128_IBM_P): Likewise. (ALTIVEC_ARG_MAX_RETURN): Likewise. * doc/extend.texi (Additional Floating Types): Document that -mfloat128 must be used to enable __float128. Document complex __float128 and __ibm128 support. [gcc/fortran] 2016-05-02 Michael Meissner * trans-types.c (gfc_build_complex_type): [gcc/testsuite] 2016-05-02 Michael Meissner * gcc.target/powerpc/float128-complex-1.c: New tests for complex __float128. * gcc.target/powerpc/float128-complex-2.c: Likewise. Index: gcc/machmode.h =================================================================== --- gcc/machmode.h (.../svn+ssh://meissner@gcc.gnu.org/svn/gcc/trunk/gcc/machmode.h) (revision 235776) +++ gcc/machmode.h (.../gcc/machmode.h) (working copy) @@ -269,6 +269,10 @@ extern const unsigned char mode_wider[NU extern const unsigned char mode_2xwider[NUM_MACHINE_MODES]; #define GET_MODE_2XWIDER_MODE(MODE) ((machine_mode) mode_2xwider[MODE]) +/* Get the complex mode from the component mode. */ +extern const unsigned char mode_complex[NUM_MACHINE_MODES]; +#define GET_MODE_COMPLEX_MODE(MODE) ((machine_mode) mode_complex[MODE]) + /* Return the mode for data of a given size SIZE and mode class CLASS. If LIMIT is nonzero, then don't use modes bigger than MAX_FIXED_MODE_SIZE. The value is BLKmode if no other mode is found. */ Index: gcc/stor-layout.c =================================================================== --- gcc/stor-layout.c (.../svn+ssh://meissner@gcc.gnu.org/svn/gcc/trunk/gcc/stor-layout.c) (revision 235776) +++ gcc/stor-layout.c (.../gcc/stor-layout.c) (working copy) @@ -2146,11 +2146,13 @@ layout_type (tree type) case COMPLEX_TYPE: TYPE_UNSIGNED (type) = TYPE_UNSIGNED (TREE_TYPE (type)); - SET_TYPE_MODE (type, - mode_for_size (2 * TYPE_PRECISION (TREE_TYPE (type)), - (TREE_CODE (TREE_TYPE (type)) == REAL_TYPE - ? MODE_COMPLEX_FLOAT : MODE_COMPLEX_INT), - 0)); + + /* build_complex_type and fortran's gfc_build_complex_type have set the + expected mode to allow having multiple complex types for multiple + floating point types that have the same size such as the PowerPC with + __ibm128 and __float128. */ + gcc_assert (TYPE_MODE (type) != VOIDmode); + TYPE_SIZE (type) = bitsize_int (GET_MODE_BITSIZE (TYPE_MODE (type))); TYPE_SIZE_UNIT (type) = size_int (GET_MODE_SIZE (TYPE_MODE (type))); break; Index: gcc/genmodes.c =================================================================== --- gcc/genmodes.c (.../svn+ssh://meissner@gcc.gnu.org/svn/gcc/trunk/gcc/genmodes.c) (revision 235776) +++ gcc/genmodes.c (.../gcc/genmodes.c) (working copy) @@ -66,6 +66,7 @@ struct mode_data this mode as a component. */ struct mode_data *next_cont; /* Next mode in that list. */ + struct mode_data *complex; /* complex type with mode as component. */ const char *file; /* file and line of definition, */ unsigned int line; /* for error reporting */ unsigned int counter; /* Rank ordering of modes */ @@ -83,7 +84,7 @@ static struct mode_data *void_mode; static const struct mode_data blank_mode = { 0, "", MAX_MODE_CLASS, -1U, -1U, -1U, -1U, - 0, 0, 0, 0, 0, + 0, 0, 0, 0, 0, 0, "", 0, 0, 0, 0, false, 0 }; @@ -472,6 +473,7 @@ make_complex_modes (enum mode_class cl, c = new_mode (cclass, buf, file, line); c->component = m; + m->complex = c; } } @@ -1381,6 +1383,22 @@ emit_mode_wider (void) } static void +emit_mode_complex (void) +{ + int c; + struct mode_data *m; + + print_decl ("unsigned char", "mode_complex", "NUM_MACHINE_MODES"); + + for_all_modes (c, m) + tagged_printf ("%smode", + m->complex ? m->complex->name : void_mode->name, + m->name); + + print_closer (); +} + +static void emit_mode_mask (void) { int c; @@ -1745,6 +1763,7 @@ emit_insn_modes_c (void) emit_mode_size (); emit_mode_nunits (); emit_mode_wider (); + emit_mode_complex (); emit_mode_mask (); emit_mode_inner (); emit_mode_unit_size (); Index: gcc/tree.c =================================================================== --- gcc/tree.c (.../svn+ssh://meissner@gcc.gnu.org/svn/gcc/trunk/gcc/tree.c) (revision 235776) +++ gcc/tree.c (.../gcc/tree.c) (working copy) @@ -8774,6 +8774,7 @@ build_complex_type (tree component_type) t = make_node (COMPLEX_TYPE); TREE_TYPE (t) = TYPE_MAIN_VARIANT (component_type); + SET_TYPE_MODE (t, GET_MODE_COMPLEX_MODE (TYPE_MODE (component_type))); /* If we already have such a type, use the old one. */ hstate.add_object (TYPE_HASH (component_type)); Index: gcc/fortran/trans-types.c =================================================================== --- gcc/fortran/trans-types.c (.../svn+ssh://meissner@gcc.gnu.org/svn/gcc/trunk/gcc/fortran/trans-types.c) (revision 235776) +++ gcc/fortran/trans-types.c (.../gcc/fortran/trans-types.c) (working copy) @@ -828,6 +828,7 @@ gfc_build_complex_type (tree scalar_type new_type = make_node (COMPLEX_TYPE); TREE_TYPE (new_type) = scalar_type; + SET_TYPE_MODE (new_type, GET_MODE_COMPLEX_MODE (TYPE_MODE (scalar_type))); layout_type (new_type); return new_type; }