public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Ilya Verbin <iverbin@gmail.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: gcc-patches@gcc.gnu.org, Kirill Yukhin <kirill.yukhin@gmail.com>
Subject: Re: [gomp4.1] Initial support for some OpenMP 4.1 construct parsing
Date: Thu, 25 Jun 2015 19:47:00 -0000	[thread overview]
Message-ID: <20150625194529.GB33078@msticlxl57.ims.intel.com> (raw)
In-Reply-To: <20150609202426.GG10247@tucnak.redhat.com>

On Tue, Jun 09, 2015 at 22:24:26 +0200, Jakub Jelinek wrote:
> On Tue, Jun 09, 2015 at 09:36:08PM +0300, Ilya Verbin wrote:
> > I don't quite understand from "If a depend clause is present, then it is treated
> > as if it had appeared on the implicit task construct that encloses the target
> > construct", is
> > 
> >   #pragma omp target depend(inout: x)
> > 
> > equivalent to
> > 
> >   #pragma omp task depend(inout: x)
> >   #pragma omp target
> > 
> > or not?
> > 
> > In other words, can't we just generate GOMP_task (...) with GOMP_target (...)
> > inside, without any new arguments?
> 
> No, that would be an explicit task.  Furthermore, the implicit task isn't
> on the host side, but on the offloading device side.  The implicit task is
> what is executed when you enter the #pragma omp target.  Ignoring the teams
> construct which is there mainly for NVidia GPGPUs, when you enter the
> #pragma omp target construct, there is an implicit parallel with
> num_threads(1) (like there is an implicit parallel with num_threads(1)
> when you enter main () of a host program), and that implicit parallel has
> a single implicit task, which executes the statements inside of #pragma
> omp target body, until you encounter #pragma omp teams or #pragma omp
> parallel.  And the above statement simply says that no statements from
> the #pragma omp target body are executed until the depend dependency is
> satisfied.  Whether these dependencies are host addresses, or offloading
> device addresses, is something that really needs to be figured out, I admit
> I haven't read the whole async offloading text carefully yet, nor
> participated in the telecons about it. 

So, as I understood, three tasks will be generated almost simultaneously in
foo1: one on host and two on target.
Target task 1 will be executed immediately.
Host task will wait for task 1 to be completed on target.
(Or it is not possible to mix "omp target" and "omp task" dependencies?)
And task 2 will wait on target for task 1.

void foo1 ()
{
  int x;

  #pragma omp parallel
  #pragma omp single
    {
      #pragma omp target nowait depend(out: x)
	fprintf (stderr, "target task 1\n");

      #pragma omp task depend(in: x)
	fprintf (stderr, "host task\n");

      #pragma omp target depend(in: x)
	fprintf (stderr, "target task 2\n");
    }
}

I just can't understand why do we need target tasks, i.e. why a host task with a
target region inside can't wait for another host task, like in foo2?

void foo2 ()
{
  int x;

  #pragma omp parallel
  #pragma omp single
    {
      #pragma omp task depend(out: x)
      #pragma omp target
	fprintf (stderr, "host task with tgt 1\n");

      #pragma omp task depend(in: x)
	fprintf (stderr, "host task\n");

      #pragma omp task depend(in: x) 
      #pragma omp target
	fprintf (stderr, "host task with tgt 2\n");
    }
}

Thanks,
  -- Ilya

  reply	other threads:[~2015-06-25 19:45 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
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 [this message]
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=20150625194529.GB33078@msticlxl57.ims.intel.com \
    --to=iverbin@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=kirill.yukhin@gmail.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).