From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30479 invoked by alias); 11 Feb 2015 14:50:36 -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 30460 invoked by uid 89); 11 Feb 2015 14:50:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 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; Wed, 11 Feb 2015 14:50:34 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1YLYcW-00058z-SZ from Thomas_Schwinge@mentor.com ; Wed, 11 Feb 2015 06:50:29 -0800 Received: from feldtkeller.schwinge.homeip.net (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.3.224.2; Wed, 11 Feb 2015 14:50:27 +0000 From: Thomas Schwinge To: Bernd Schmidt CC: GCC Patches , Jakub Jelinek Subject: [nvptx] -freorder-blocks-and-partition, -freorder-functions (was: nvptx offloading patches [4/n]) In-Reply-To: <87fvacld85.fsf@kepler.schwinge.homeip.net> References: <5454CDF1.3070307@codesourcery.com> <87fvacld85.fsf@kepler.schwinge.homeip.net> User-Agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/24.4.1 (i586-pc-linux-gnu) Date: Wed, 11 Feb 2015 14:50:00 -0000 Message-ID: <87a90klcyb.fsf@kepler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-SW-Source: 2015-02/txt/msg00714.txt.bz2 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-length: 2238 Hi! On Wed, 11 Feb 2015 15:44:26 +0100, I wrote: > If -freorder-blocks-and-partition is active, this results in PTX code > such as: >=20 > // BEGIN PREAMBLE > .version 3.1 > .target sm_30 > .address_size 64 > // END PREAMBLE >=20=20=20=20=20 > $LCOLDB0: > $LHOTB0: > // BEGIN FUNCTION DECL: vec_mult$_omp_fn$1 > .entry vec_mult$_omp_fn$1(.param.u64 %in_ar1); > // BEGIN FUNCTION DEF: vec_mult$_omp_fn$1 > .entry vec_mult$_omp_fn$1(.param.u64 %in_ar1) > { > .reg.u64 %ar1; > [...] >=20 > Note the global cold/hot labels. Such partitioning might not make a lot of sense for the virtual ISA that PTX is, but disabling it in nvptx.c:nvptx_option_override does not work. (Because that is not invoked in the offloading code path?) I see x86 has a ix86_option_override_internal (but I don't know how that options processing works) -- is something like that needed for nvptx, too, and how to interconnect that with the offloading code path? Sounds a bit like what Jakub suggests in ? Maybe -freorder-functions (of no use?) should also be disabled? Here is a WIP patch for -freorder-blocks-and-partition (missing handling of the offloading code path) -- does something like that make sense? --- gcc/config/nvptx/nvptx.c +++ gcc/config/nvptx/nvptx.c @@ -93,6 +93,18 @@ nvptx_option_override (void) init_machine_status =3D nvptx_init_machine_status; /* Gives us a predictable order, which we need especially for variables.= */ flag_toplevel_reorder =3D 1; + /* If enabled, global cold/hot labels will be emitted, which our mkofflo= ad + currently doesn't cope with. Also, it's not clear whether such + partitioning actually has any positive effect on the virtual ISA that= PTX + is. */ + if (flag_reorder_blocks_and_partition) + { + inform (input_location, + "-freorder-blocks-and-partition not supported on this " + "architecture"); + flag_reorder_blocks_and_partition =3D 0; + flag_reorder_blocks =3D 1; + } /* Assumes that it will see only hard registers. */ flag_var_tracking =3D 0; write_symbols =3D NO_DEBUG; Gr=C3=BC=C3=9Fe, Thomas --=-=-= Content-Type: application/pgp-signature; name="signature.asc" Content-length: 472 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJU22wsAAoJEK3/DN1sMFFtPewH/RH2avRYVI0cDLvAt/Kyl33Z 7aEz+4F4FFhLgqxwPJH4kMN7yfi2hlIBthUAnnh9Kx27eNB+lYKV2kJJO4IM1gRv 64hCw38WWl538/t9/m6A2hjUZV3YNsiiL1yYKrd3JimPhZtdrbayFJTwY/7PCGuS FMnCSl3GOA6TJaukqRY9FEdbgrjqwhXwcln8rEmK7bhvU3+5JwR3eZbi3RKjo/KZ jpKAaubKhJslYlyLKAAtphv0stwc/s6lnUWGvl0ElbOOtgBLMda6KYVgYs+vL5Ie esdFoAQkO+be7x3/zcoGD9Qy9ygaM6e729kCPfNuCm6yz94TU5jGzTrwC4yyIjg= =I8fu -----END PGP SIGNATURE----- --=-=-=--