Hi!
On Thu, 21 Jan 2016 22:54:26 +0100, I wrote:
> Committed to gomp-4_0-branch in r232709:
>
> commit 41a76d233e714fd7b79dc1f40823f607c38306ba
> Author: tschwinge
> Date: Thu Jan 21 21:52:50 2016 +0000
>
> Un-parallelized OpenACC kernels constructs with nvp
le stuff]
>
> 2) a new GCC-specific clause, for example in the implementation
> namespace, starting with "_":
>
> #pragma acc kernels _force_offloading
> [un-parallelizable stuff]
>
> ..., the -foffload-force flag was the simplest solution. (Beca
Hi!
On Thu, 21 Jan 2016 22:54:26 +0100, I wrote:
> Committed to gomp-4_0-branch in r232709:
>
> commit 41a76d233e714fd7b79dc1f40823f607c38306ba
> Author: tschwinge
> Date: Thu Jan 21 21:52:50 2016 +0000
>
> Un-parallelized OpenACC kernels constructs with nvp
On 02/11/2016 11:01 AM, Thomas Schwinge wrote:
The "avoid offloading" mechanism. Owed to the non-shared-memory
offloading architecture, if the compiler/runtime decides to "avoid
offloading", then this has to apply to *all* code offloading, for data
consistency reasons. Do we agree on that?
N
Hi!
There are two issues here: 1. "avoid offloading" mechanism, and 2. "avoid
offloading" policy.
On Wed, 10 Feb 2016 21:07:29 +0100, Bernd Schmidt wrote:
> On 02/10/2016 06:37 PM, Thomas Schwinge wrote:
> > On Wed, 10 Feb 2016 17:37:30 +0100, Bernd Schmidt
> > wrote:
> >> IIUC it's also disab
On 02/10/2016 06:37 PM, Thomas Schwinge wrote:
On Wed, 10 Feb 2016 17:37:30 +0100, Bernd Schmidt wrote:
IIUC it's also disabling offloading for parallels rather than just
kernels, which we previously said shouldn't happen.
Ah, you're talking about mixed OpenACC parallel/kernels codes -- I
und
Hi!
On Wed, 10 Feb 2016 17:37:30 +0100, Bernd Schmidt wrote:
> On 02/10/2016 05:23 PM, Thomas Schwinge wrote:
> > Why? A user of GCC has no intrinsic interest in getting OpenACC kernels
> > constructs' code offloaded; the user wants his code to execute as fast as
> > possible.
> >
> > If you con
On 02/10/2016 05:23 PM, Thomas Schwinge wrote:
Why? A user of GCC has no intrinsic interest in getting OpenACC kernels
constructs' code offloaded; the user wants his code to execute as fast as
possible.
If you consider the whole of OpenACC kernels code offloading as a
compiler optimization, the
Hi!
On Wed, 10 Feb 2016 16:27:40 +0100, Bernd Schmidt wrote:
> On 02/10/2016 03:39 PM, Thomas Schwinge wrote:
>
> > Yes, we need a hammer that big: we have to ensure consistency between
> > data regions on the device and code offloading to the device, as
> > otherwise we'll very easily run into
On 02/10/2016 03:39 PM, Thomas Schwinge wrote:
Yes, we need a hammer that big: we have to ensure consistency between
data regions on the device and code offloading to the device, as
otherwise we'll very easily run into inconsistencies, because of the
non-shared memory. In the general case, it's
Hi!
On Wed, 10 Feb 2016 14:25:50 +0100, Bernd Schmidt wrote:
> On 02/10/2016 12:49 PM, Thomas Schwinge wrote:
> > [...]
>
> I think this has to be considered after gcc-6.
Hmm, I see.
> In general, what's the
> state of OpenACC these days?
Much improved compared to GCC 5. :-) Anything speci
On 02/10/2016 12:49 PM, Thomas Schwinge wrote:
Hi!
Ping.
I think this has to be considered after gcc-6. In general, what's the
state of OpenACC these days?
I'm slightly confused by the interface between offloaded code and
libgomp. It looks like you're collecting avoid-offloading flags
per
t; Author: Thomas Schwinge
> Date: Tue Feb 2 20:41:42 2016 +0100
>
> Un-parallelized OpenACC kernels constructs with nvptx offloading: "avoid
> offloading"
>
> gcc/
> * common.opt: Add -foffload-force.
> * lto-wrapper.c (merge_
d
code (and the "avoid offloading" handling will no longer trigger). OK to
commit?
commit acd66946777671486a0f69706b25a3ec5f877306
Author: Thomas Schwinge
Date: Tue Feb 2 20:41:42 2016 +0100
Un-parallelized OpenACC kernels constructs with nvptx offloading: "avoid
offloading"
On Fri, Jan 22, 2016 at 02:18:38PM +0100, Bernd Schmidt wrote:
> On 01/22/2016 09:36 AM, Jakub Jelinek wrote:
> >
> >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
On 01/22/2016 02:25 PM, Jakub Jelinek wrote:
What about #pragma oacc parallel? That would never do that?
It shouldn't, no (IMO).
Bernd
On Fri, Jan 22, 2016 at 02:18:38PM +0100, Bernd Schmidt wrote:
> On 01/22/2016 09:36 AM, Jakub Jelinek wrote:
> >
> >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
On 01/22/2016 09:36 AM, Jakub Jelinek wrote:
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).
emory)
> > > offloading targets.
> >
> > > Committed to gomp-4_0-branch in r232709:
> > >
> > > commit 41a76d233e714fd7b79dc1f40823f607c38306ba
> > > Author: tschwinge
> > > Date: Thu Jan 21 21:52:50 2016 +
> > >
>
bination 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
>
shared memory)
> offloading targets.
> Committed to gomp-4_0-branch in r232709:
>
> commit 41a76d233e714fd7b79dc1f40823f607c38306ba
> Author: tschwinge
> Date: Thu Jan 21 21:52:50 2016 +
>
> 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?
Grüße
Thomas
Committed to gomp-4_0-branch in r232709:
commit 41a76d233e714fd7b79dc1f40823f607c38306ba
Author: tschwinge
Date: Thu Jan 21 21:52:50 2016 +
Un-parallelized OpenACC kernels constructs with nvptx offloading: "avoid
offloading"
gcc/
* common.opt: Add -foffloa
22 matches
Mail list logo
