public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Thomas Schwinge <thomas@codesourcery.com>
Cc: gcc-patches@gcc.gnu.org, Kirill Yukhin <kirill.yukhin@gmail.com>,
	       Richard Henderson <rth@redhat.com>
Subject: Re: [gomp4.1] Initial support for some OpenMP 4.1 construct parsing
Date: Wed, 29 Apr 2015 12:31:00 -0000	[thread overview]
Message-ID: <20150429120644.GG1751@tucnak.redhat.com> (raw)
In-Reply-To: <874mnzrw1z.fsf@schwinge.name>

On Wed, Apr 29, 2015 at 01:52:24PM +0200, Thomas Schwinge wrote:
> Hi Jakub!
> 
> (I have not yet read any version of the OpenMP 4.1 standard.)

There is no OpenMP 4.1 standard, just the public TR3 released in November
last year, and then some non-public WIP.

> > +  tree stmt = make_node (OMP_TARGET_DATA);
> > +  TREE_TYPE (stmt) = void_type_node;
> > +  OMP_TARGET_DATA_CLAUSES (stmt) = clauses;
> 
> Even if it doesn't make a lot of sense, my reading of OpenMP 4.0 has been
> that a target data construct without any map clauses is still valid.
> (But I have not verified that now.)

Yes, it is valid in OpenMP 4.0.  But in GCC we're just supporting the latest
standard, there is no -fopenmp={2.5,3.0,3.1,4.0,4.1} like there is
-std=c{89,99,11}.

> > --- gcc/omp-low.c.jj	2015-04-29 10:58:01.489748182 +0200
> > +++ gcc/omp-low.c	2015-04-29 11:03:04.646991017 +0200
> > @@ -8994,6 +9017,11 @@ expand_omp_target (struct omp_region *re
> >      case GF_OMP_TARGET_KIND_UPDATE:
> >        start_ix = BUILT_IN_GOMP_TARGET_UPDATE;
> >        break;
> > +    case GF_OMP_TARGET_KIND_ENTER_DATA:
> > +    case GF_OMP_TARGET_KIND_EXIT_DATA:
> > +      /* FIXME */
> > +      start_ix = BUILT_IN_GOMP_TARGET_UPDATE;
> > +      break;
> 
> Actually, I've also wondered (but never verified) whether all of the
> OpenACC enter, exit, and update constructs can be implemented via the
> same libgomp API.

Well, the behavior is different.  The draft requires only alloc or to
(or always, variants) for enter data and only from or delete (or always,
variants) for exit data, so in theory it is possible to figure that from
the call without extra args, but not so for update - enter data is supposed
to increment reference counts, exit data decrement.  And, we'll need new
arguments for async (pass through info that it is async (nowait) or sync,
and the depend clause address(es)).

> 
> > @@ -11488,6 +11520,9 @@ lower_omp_target (gimple_stmt_iterator *
> >  	      default:
> >  		gcc_unreachable ();
> >  	      }
> > +	    /* FIXME: Temporary hack.  */
> > +	    if (talign_shift == 3)
> > +	      tkind &= ~GOMP_MAP_FLAG_FORCE;
> >  	    gcc_checking_assert (tkind
> >  				 < (HOST_WIDE_INT_C (1U) << talign_shift));
> >  	    talign = ceil_log2 (talign);
> 
> Assuming you'll be changing the relevant functions' APIs, and assigning
> new ABI versions, don't forget to also drop the unused offload_table
> formal parameter (assuming that it remains unused).

Yeah, we'll need new GOMP_target{,_data,_end_data,_update} replacements.

> > --- gcc/tree-pretty-print.c.jj	2015-04-29 10:58:01.663745452 +0200
> > +++ gcc/tree-pretty-print.c	2015-04-29 11:03:04.648990986 +0200
> > @@ -550,22 +560,22 @@ dump_omp_clause (pretty_printer *pp, tre
> >  	  pp_string (pp, "tofrom");
> >  	  break;
> >  	case GOMP_MAP_FORCE_ALLOC:
> > -	  pp_string (pp, "force_alloc");
> > +	  pp_string (pp, "always,alloc");
> >  	  break;
> >  	case GOMP_MAP_FORCE_TO:
> > -	  pp_string (pp, "force_to");
> > +	  pp_string (pp, "always,to");
> >  	  break;
> >  	case GOMP_MAP_FORCE_FROM:
> > -	  pp_string (pp, "force_from");
> > +	  pp_string (pp, "always,from");
> >  	  break;
> >  	case GOMP_MAP_FORCE_TOFROM:
> > -	  pp_string (pp, "force_tofrom");
> > +	  pp_string (pp, "always,tofrom");
> >  	  break;
> >  	case GOMP_MAP_FORCE_PRESENT:
> >  	  pp_string (pp, "force_present");
> >  	  break;
> >  	case GOMP_MAP_FORCE_DEALLOC:
> > -	  pp_string (pp, "force_dealloc");
> > +	  pp_string (pp, "always,delete");
> >  	  break;
> >  	case GOMP_MAP_FORCE_DEVICEPTR:
> >  	  pp_string (pp, "force_deviceptr");
> 
> Makes some sense to me to use the same "always,*" syntax also for the
> other "force_*" ones, given that these are artificial ("non-OpenACC")
> descriptions anyway.

Ok.  Are the GOMP_MAP_FORCE_* artificial too?  If yes, I can change that
to GOMP_MAP_ALWAYS_*.

Anyway, for most of the further 4.1 offloading I'll defer to Ilya Verbin and
Kyrill as agreed privately on IRC, I'll focus for now on the task / doacross
etc. stuff for now (and, hopefully if enough of the OpenACC stuff is merged
in soon, restart work on the OpenMP 4.0 / NVPTX offloading too, but that not
on this branch).

	Jakub

  reply	other threads:[~2015-04-29 12:06 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-29 11:44 Jakub Jelinek
2015-04-29 11:55 ` Thomas Schwinge
2015-04-29 12:31   ` Jakub Jelinek [this message]
2015-04-29 15:20     ` Thomas Schwinge
2015-06-09 18:39     ` Ilya Verbin
2015-06-09 20:25       ` Jakub Jelinek
2015-06-25 19:47         ` Ilya Verbin
2015-06-25 20:31           ` Jakub Jelinek
2015-07-17 16:47             ` Ilya Verbin
2015-07-17 16:54               ` Jakub Jelinek
2015-07-20 16:18                 ` Jakub Jelinek
2015-07-20 18:31                   ` Jakub Jelinek
2015-07-23  0:50                     ` Jakub Jelinek
2015-07-24 20:33                       ` Jakub Jelinek
2015-07-29 17:30                         ` [gomp4.1] Various accelerator updates from OpenMP 4.1 Jakub Jelinek
2015-09-04 18:17                           ` Ilya Verbin
2015-09-04 18:25                             ` Jakub Jelinek
2015-09-07 12:48                             ` Jakub Jelinek
2015-07-20 19:40                 ` [gomp4.1] Initial support for some OpenMP 4.1 construct parsing Ilya Verbin
2015-08-24 12:38                   ` Jakub Jelinek
2015-08-24 19:10                     ` Ilya Verbin
2015-06-11 12:52       ` [gomp4.1] map clause parsing improvements Jakub Jelinek
2015-10-19 10:34         ` Thomas Schwinge
2015-10-19 10:46           ` Jakub Jelinek
2015-10-19 15:14             ` Thomas Schwinge
2015-10-20 10:10               ` Jakub Jelinek
2015-10-26 13:04                 ` Ilya Verbin
2015-10-26 13:17                   ` Jakub Jelinek
2015-10-26 14:16                     ` Ilya Verbin
2016-03-17 14:34             ` Thomas Schwinge
2016-03-17 14:37               ` Jakub Jelinek
2016-03-17 14:55                 ` Jakub Jelinek
2016-03-17 15:13                 ` Rename GOMP_MAP_FORCE_DEALLOC to GOMP_MAP_DELETE (was: [gomp4.1] map clause parsing improvements) 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=20150429120644.GG1751@tucnak.redhat.com \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=kirill.yukhin@gmail.com \
    --cc=rth@redhat.com \
    --cc=thomas@codesourcery.com \
    /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).