diff mbox

nvptx offloading patches [4/n]

Message ID 87fvacld85.fsf@kepler.schwinge.homeip.net
State New
Headers show

Commit Message

Thomas Schwinge Feb. 11, 2015, 2:44 p.m. UTC 
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?



Grüße,
 Thomas

Comments

Bernd Schmidt Feb. 11, 2015, 3:20 p.m. UTC | #1 
On 02/11/2015 03:44 PM, Thomas Schwinge wrote:
> 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?

I'd rather fail if anything unexpected is seen. Things like 
-freorder-blocks-and-partition should be forced off in 
nvptx_option_override.


Bernd
Thomas Schwinge Feb. 17, 2015, 6:13 p.m. UTC | #2 
Hi!

On Wed, 11 Feb 2015 16:20:51 +0100, Bernd Schmidt <bernds@codesourcery.com> wrote:
> On 02/11/2015 03:44 PM, Thomas Schwinge wrote:
> > 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?

Committed to trunk in r220769.


> I'd rather fail if anything unexpected is seen. Things like 
> -freorder-blocks-and-partition should be forced off in 
> nvptx_option_override.

Yes; that's basically what I suggested in my other email,
<http://news.gmane.org/find-root.php?message_id=%3C87a90klcyb.fsf%40kepler.schwinge.homeip.net%3E>.


Grüße,
 Thomas
diff mbox

Patch

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