This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: nvptx offloading patches [4/n]


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: signature.asc
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]