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
Subject: Re: [gomp4] Un-parallelized OpenACC kernels constructs with nvptx offloading: "avoid offloading"
Date: Fri, 22 Jan 2016 08:36:00 -0000	[thread overview]
Message-ID: <20160122083625.GL3017@tucnak.redhat.com> (raw)
In-Reply-To: <87a8nyawph.fsf@hertz.schwinge.homeip.net>

On Fri, Jan 22, 2016 at 08:40:26AM +0100, Thomas Schwinge wrote:
> On Thu, 21 Jan 2016 22:54:26 +0100, I wrote:
> > On Mon, 18 Jan 2016 18:26:49 +0100, Tom de Vries <Tom_deVries@mentor.com> wrote:
> > > [...] [OpenACC] kernels region [...]
> > > that parloops does not manage to parallelize:
> 
> > Telling from real-world code that we've been having a look at, when the
> > above situation happens, we're -- in the vast majority of all cases -- in
> > a situation where we generally want to avoid offloading (unless
> > explicitly requested), "to avoid data copy penalty" as well as typically
> > much slower single-threaded execution on the GPU.  Obviously, that will
> > have to be revisited as parloops (or any other mechanism in GCC) is able
> > to better understand/use the parallelism in OpenACC kernels constructs.
> > 
> > So, building upon Tom's patch, I have implemented an "avoid offloading"
> > flag given the presence of one un-parallelized OpenACC kernels construct.
> > This is currently only enabled for OpenACC kernels constructs, in
> > combination with nvptx offloading, but I think the general scheme will be
> > useful also for other constructs as well as other (non-shared memory)
> > offloading targets.
> 
> > Committed to gomp-4_0-branch in r232709:
> > 
> > commit 41a76d233e714fd7b79dc1f40823f607c38306ba
> > Author: tschwinge <tschwinge@138bc75d-0d04-0410-961f-82ee72b054a4>
> > Date:   Thu Jan 21 21:52:50 2016 +0000
> > 
> >     Un-parallelized OpenACC kernels constructs with nvptx offloading: "avoid offloading"
> 
> Thought I'd check before porting it over -- will such a patch also be
> accepted for trunk?

I think it is a bad idea to go against what the user wrote.  Warning that
some code might not be efficient?  Perhaps (if properly guarded with some
warning option one can turn off, either on a per-source file or using
pragmas even more fine grained).  But by default not offloading?  That is
just wrong.

	Jakub

  reply	other threads:[~2016-01-22  8:36 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87r3hac1w9.fsf@hertz.schwinge.homeip.net>
2016-01-18 17:27 ` [PATCH] Add fopt-info-oacc Tom de Vries
2016-01-18 18:28   ` Sandra Loosemore
2016-01-18 20:30     ` Richard Sandiford
2016-01-21 21:55   ` [gomp4] Un-parallelized OpenACC kernels constructs with nvptx offloading: "avoid offloading" (was: [PATCH] Add fopt-info-oacc) Thomas Schwinge
2016-01-22  7:40     ` [gomp4] Un-parallelized OpenACC kernels constructs with nvptx offloading: "avoid offloading" Thomas Schwinge
2016-01-22  8:36       ` Jakub Jelinek [this message]
2016-01-22  9:00         ` Thomas Schwinge
2016-01-22 13:18         ` Bernd Schmidt
2016-01-22 13:25           ` Jakub Jelinek
2016-01-22 13:31             ` Bernd Schmidt
2016-02-04 14:47               ` Thomas Schwinge
2016-02-10 11:51                 ` Thomas Schwinge
2016-02-10 13:25                   ` Bernd Schmidt
2016-02-10 14:40                     ` Thomas Schwinge
2016-02-10 15:27                       ` Bernd Schmidt
2016-02-10 16:23                         ` Thomas Schwinge
2016-02-10 16:37                           ` Bernd Schmidt
2016-02-10 17:39                             ` Thomas Schwinge
2016-02-10 20:07                               ` Bernd Schmidt
2016-02-11 10:02                                 ` Thomas Schwinge
2016-02-11 15:58                                   ` Bernd Schmidt
2016-01-26 22:30           ` [gomp4] " Martin Jambor
2016-06-30 21:46     ` Thomas Schwinge
2016-11-03 17:59     ` [gomp4] Un-parallelized OpenACC kernels constructs with nvptx offloading: "avoid offloading" (was: [PATCH] Add fopt-info-oacc) Cesar Philippidis
2019-01-31 17:16     ` [gomp4] Un-parallelized OpenACC kernels constructs with nvptx offloading: "avoid offloading" 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=20160122083625.GL3017@tucnak.redhat.com \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --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).