This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Un-parallelized OpenACC kernels constructs with nvptx offloading: "avoid offloading"
- From: Thomas Schwinge <thomas at codesourcery dot com>
- To: Bernd Schmidt <bschmidt at redhat dot com>, Jakub Jelinek <jakub at redhat dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>, Tom de Vries <vries at codesourcery dot com>
- Date: Wed, 10 Feb 2016 15:39:48 +0100
- Subject: Re: Un-parallelized OpenACC kernels constructs with nvptx offloading: "avoid offloading"
- Authentication-results: sourceware.org; auth=none
- References: <87r3hac1w9 dot fsf at hertz dot schwinge dot homeip dot net> <569D2059 dot 4010105 at mentor dot com> <87d1subnu5 dot fsf at hertz dot schwinge dot homeip dot net> <87a8nyawph dot fsf at hertz dot schwinge dot homeip dot net> <20160122083625 dot GL3017 at tucnak dot redhat dot com> <56A22C2E dot 6000408 at redhat dot com> <20160122132538 dot GT3017 at tucnak dot redhat dot com> <56A22F37 dot 5010505 at redhat dot com> <87zivg8rcy dot fsf at hertz dot schwinge dot homeip dot net> <87h9hg9450 dot fsf at hertz dot schwinge dot homeip dot net> <56BB3A5E dot 6000506 at redhat dot com>
Hi!
On Wed, 10 Feb 2016 14:25:50 +0100, Bernd Schmidt <bschmidt@redhat.com> 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 specific you'd like me to
elaborate on? <https://gcc.gnu.org/wiki/OpenACC> should be fairly
accurate.
> I'm slightly confused by the interface between offloaded code and
> libgomp. It looks like you're collecting avoid-offloading flags
> per-function, but then when things get registered, it seems like a
> per-image flag.
(Per-image flag that affects all offloading for a given offloading type,
even.)
> Is that right? It seems like too large a hammer.
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 "all or nothing": you
either have to offload all kernels or none of them.
> >> [...]
>
> Avoid unnecessary braces.
>
> >> [...]
>
> Typo.
Thanks for the review; fixed.
GrÃÃe
Thomas