[gomp4] Un-parallelized OpenACC kernels constructs with nvptx offloading: "avoid offloading"

[Jakub Jelinek]

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