public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Thomas Schwinge <thomas@codesourcery.com>
To: Bernd Schmidt <bernds@codesourcery.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: nvptx offloading patches [4/n]
Date: Wed, 11 Feb 2015 14:44:00 -0000	[thread overview]
Message-ID: <87fvacld85.fsf@kepler.schwinge.homeip.net> (raw)
In-Reply-To: <5454CDF1.3070307@codesourcery.com>

[-- Attachment #1: Type: text/plain, Size: 2275 bytes --]

Hi Bernd!

On Sat, 1 Nov 2014 13:11:29 +0100, Bernd Schmidt <bernds@codesourcery.com> 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?

--- 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;
 }


Grüße,
 Thomas

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

  parent reply	other threads:[~2015-02-11 14:44 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-01 12:11 Bernd Schmidt
2015-01-28 18:03 ` Thomas Schwinge
2015-01-28 18:16   ` Ilya Verbin
2015-02-11 14:20     ` Thomas Schwinge
2015-02-11 14:19   ` Thomas Schwinge
2015-02-11 14:20   ` Thomas Schwinge
2015-02-11 14:44 ` Thomas Schwinge [this message]
2015-02-11 14:50   ` [nvptx] -freorder-blocks-and-partition, -freorder-functions (was: nvptx offloading patches [4/n]) Thomas Schwinge
2015-02-25 10:54     ` Option overriding in the offloading code path (was: [nvptx] -freorder-blocks-and-partition, -freorder-functions) Thomas Schwinge
2015-02-25 13:23       ` Option overriding in the offloading code path Bernd Schmidt
2015-02-25 17:15       ` Option overriding in the offloading code path (was: [nvptx] -freorder-blocks-and-partition, -freorder-functions) Jakub Jelinek
2015-02-26 10:42         ` var-tracking vs. pseudo registers (was: Option overriding in the offloading code path) Thomas Schwinge
2015-02-26 10:53           ` Jakub Jelinek
2015-03-26 11:00             ` [PATCH] Don't run var-tracking for targetm.no_register_allocation targets Jakub Jelinek
2015-03-26 11:20               ` Richard Biener
2015-04-27 16:44               ` var-tracking vs. pseudo registers (was: Option overriding in the offloading code path) Thomas Schwinge
2015-03-13  9:07       ` Option overriding in the offloading code path Thomas Schwinge
2015-02-11 15:21   ` nvptx offloading patches [4/n] Bernd Schmidt
2015-02-17 18:14     ` Thomas Schwinge
2015-02-18  8:26 ` nvptx mkoffload: For non-installed testing, look in all COMPILER_PATHs for GCC_INSTALL_NAME (was: nvptx offloading patches [4/n]) Thomas Schwinge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fvacld85.fsf@kepler.schwinge.homeip.net \
    --to=thomas@codesourcery.com \
    --cc=bernds@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).