From patchwork Wed Feb 11 14:44:26 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Thomas Schwinge X-Patchwork-Id: 438794 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 749671402A9 for ; Thu, 12 Feb 2015 01:45:52 +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=j1aw0VmZRiO8CvQA NuyKwH22w5BDhLTx7xtprIbcvy+3TWlytsj5bXiWgnC5LLeQ2GHSifwvLIKcj5QR F/xTgzdg6PNirQgHgcPKMC13qvYNnaVNrnyDwWkpIVqICn4cF6yBFszqVOaCEBle AlBl6T57uQDjT/LUAyq4QCGASbU= 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=7MnfZ9fXSe18PiI86hkSSB Nuadk=; b=F+d3DvGB5el+JnfANsxvAK0djY2Ga86l1FhdktQ5DW8bk8fUBJiGhn dJ7R8Z6tfUMg8qevLEgoLawexFNGtpOvECEoq0HI/lu4GYJC/m/0tPB6XbLFJTNZ pVGDydhwdc/3TlmNzc+shd+sKCbdE5fsA94DLd/8jKCVXW5qfldDs= Received: (qmail 30695 invoked by alias); 11 Feb 2015 14:44: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 30652 invoked by uid 89); 11 Feb 2015 14:44:40 -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:44:39 +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 1YLYWp-0003ND-Lw from Thomas_Schwinge@mentor.com for gcc-patches@gcc.gnu.org; Wed, 11 Feb 2015 06:44:36 -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:44:34 +0000 From: Thomas Schwinge To: Bernd Schmidt CC: GCC Patches Subject: Re: nvptx offloading patches [4/n] In-Reply-To: <5454CDF1.3070307@codesourcery.com> References: <5454CDF1.3070307@codesourcery.com> User-Agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/24.4.1 (i586-pc-linux-gnu) Date: Wed, 11 Feb 2015 15:44:26 +0100 Message-ID: <87fvacld85.fsf@kepler.schwinge.homeip.net> MIME-Version: 1.0 Hi Bernd! On Sat, 1 Nov 2014 13:11:29 +0100, Bernd Schmidt wrote: > I'm sending this for reference more than anything else - this is the > patch that adds the target support for offloading to the nvptx port. (I committed this in r220209.) > I actually expect this to change a little in the near future; the nvptx > mkoffload duplicates some of the logic that we have in nvptx-as and I'm > thinking of making some improvements. But I figure it would be good to > show the entire picture, as it is as of now. I'm aware this is in progress, and will replace the code I'm commenting on below. Just to make sure that similar issues don't exist in nvptx-as, too. > --- /dev/null > +++ git/gcc/config/nvptx/mkoffload.c > +static Token * > +parse_file (Token *tok) > +{ > + [...] > + else > + { > + /* Something strange. Ignore it. */ > + if (comment) > + append_stmt (&fns, comment); > + > + while (tok->kind && !tok->end) > + tok++; > + } > + return tok; > +} I'm not sure if silently ignoring "strange" tokens is a good strategy? 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. This confuses mkoffload, and it runs into a busy loop due to what I understand to be a bug in skipping of "strange" tokens, cited above, which such global labels would fall under. Here is what might be a fix for this (but I didn't analyze the parsing code in detail); OK for trunk? Grüße, Thomas --- gcc/config/nvptx/mkoffload.c +++ gcc/config/nvptx/mkoffload.c @@ -755,8 +755,9 @@ parse_file (Token *tok) if (comment) append_stmt (&fns, comment); - while (tok->kind && !tok->end) + do tok++; + while (tok->kind && !tok->end); } return tok; }