From patchwork Wed Feb 11 14:50:20 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Thomas Schwinge X-Patchwork-Id: 438798 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 9F22D14028E for ; Thu, 12 Feb 2015 01:51:36 +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:from :to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-type; q=dns; s=default; b=tm3ZShQjinH/iUWV V+dz8LvRWCCEy1PXH0qLIYugbjVuN9HiM8a9zlQ+3aSyNRWqB3jByNsI1PJPfyIB 2yLIavZfYAgad7YKBr17SXeKjdyQwW9fIxHSG4uS8lBPmVrBlwoGAFivJ2akeD9N z+Qi5eCqUY+OgbZxEDRot58JdPE= 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:from :to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-type; s=default; bh=vKtOiNfJRnBmobgDRWpF4/ fEdaM=; b=uTA49mc5miiHZyYWdxQMcM69oKC6sercYy+a9xbmBLLfSru18fRhNh BJFKmFNmG2TjHXtf6b5C1UqXXMFYTDBj/Rm6yTfqHMfFRtKh5oNrpUBcJofkTLr+ eIriwHJJQ120/W6DFLzjDhOJyce+QsP/sDFNkssm1h0mHlMXwASz8= 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-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 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 15:50:20 +0100 Message-ID: <87a90klcyb.fsf@kepler.schwinge.homeip.net> MIME-Version: 1.0 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: > > // BEGIN PREAMBLE > .version 3.1 > .target sm_30 > .address_size 64 > // END PREAMBLE > > $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; > [...] > > 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? Grüße, Thomas --- gcc/config/nvptx/nvptx.c +++ gcc/config/nvptx/nvptx.c @@ -93,6 +93,18 @@ nvptx_option_override (void) init_machine_status = nvptx_init_machine_status; /* Gives us a predictable order, which we need especially for variables. */ flag_toplevel_reorder = 1; + /* If enabled, global cold/hot labels will be emitted, which our mkoffload + 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 = 0; + flag_reorder_blocks = 1; + } /* Assumes that it will see only hard registers. */ flag_var_tracking = 0; write_symbols = NO_DEBUG;