libgomp: plugin for non-shared memory host execution

[Thomas Schwinge <thomas at codesourcery dot com>]

Hi!

While I still think that a generic libgomp plugin for non-shared memory
host execution is a good idea conceptually, for the following reasons:

On Wed, 19 Feb 2014 17:10:15 +0100, I wrote:
> On Thu, 12 Dec 2013 12:31:40 +0100, I wrote:
> > On Fri, 8 Nov 2013 16:40:00 +0100, Jakub Jelinek <jakub@redhat.com> wrote:
> > > [...], device 257 is just a temporary testing hack, [...]
> > 
> > > [...], once we have at least one supported offloading target,
> > > hopefully we'll nuke device 257.
> > 
> > Hmm, in contrast, I'd advocate to preserve that device, under a proper
> > ID, for two (similar) reasons: even if it's the same architecture, we'll
> > still want a generic non-shared-memory "offloading target" for GCC
> > testsuite usage.  We can't assume that any of the "real hardware"
> > acceleration devices to be available, but will still want to test the
> > non-shared-memory stuff.  And likewise, GCC users can use this for
> > testing their code for shared-memory host (fallback) execution vs.
> > non-shared-memory execution.  So basically, just like a user can decide
> > to use OpenMP/libgomp, but tie the runtime down to just one thread; but
> > that's still different from host fallback execution.  Makes sense?
> 
> Here is such a libgomp plugin plus the infrastructure for initial support
> of non-shared memory host execution.  [...]

... the libgomp plugin as it is currently implemented fails to adequately
provide such functionality: nobody so far has implemented support for
certain data mapping constructs; so it is not currently used for OpenMP
offloading testing, and also disabled for certain OpenACC offloading test
cases.  Its improper integration into the offloading compilation process,
<https://gcc.gnu.org/wiki/Offloading#Compilation_process>, is also
causing issues: we use the target compiler for compiling "device" code --
but it doesn't know that it's being used for that purpose, so cannot
properly handle some constructs, such as efficiently implement
acc_on_device with constant argument.

It has been useful for initial bring-up, to test-drive the libgomp plugin
interface, when the nvptx backend and libgomp nvptx plugin as well as the
intelmic plugin were not yet available, but it's now probably time to
retire this plugin, at least until somebody feels like working on
integrating and implementing it properly.  Unless there are any
objections, I'll later propose a patch to this effect.


GrÃÃe,
 Thomas

Attachment: signature.asc
Description: PGP signature