Re: [gomp4.1] Handle new form of #pragma omp declare target

[Jakub Jelinek <jakub@redhat.com>]

On Mon, Oct 26, 2015 at 10:39:04PM +0300, Ilya Verbin wrote:
> > Without declare target link or to, you can't use the global variables
> > in orphaned accelerated routines (unless you e.g. take the address of the
> > mapped variable in the region and pass it around).
> > The to variables (non-deferred) are always mapped and are initialized with
> > the original initializer, refcount is infinity.  link (deferred) work more
> > like the normal mapping, referencing those vars when they aren't explicitly
> > (or implicitly) mapped is unspecified behavior, if it is e.g. mapped freshly
> > with to kind, it gets the current value of the host var rather than the
> > original one.  But, beyond the mapping the compiler needs to ensure that
> > all uses of the link global var (or perhaps just all uses of the link global
> > var outside of the target construct body where it is mapped, because you
> > could use there the pointer you got from GOMP_target) are replaced by
> > dereference of some artificial pointer, so a becomes *a_tmp and &a becomes
> > &*a_tmp, and that the runtime library during registration of the tables is
> > told about the address of this artificial pointer.  During registration,
> > I'd expect it would stick an entry for this range into the table, with some
> > special flag or something similar, indicating that it is deferred mapping
> > and where the offloading device pointer is.  During mapping, it would map it
> > as any other not yet mapped object, but additionally would also set this
> > device pointer to the device address of the mapped object.  We also need to
> > ensure that when we drop the refcount of that mapping back to 0, we get it
> > back to the state where it is described as a range with registered deferred
> > mapping and where the device pointer is.
> 
> Ok, got it, I'll try implement this...

Thanks.

> > > > we actually replace the variables with pointers to variables, then need
> > > > to somehow also mark those in the offloading tables, so that the library
> > > 
> > > I see 2 possible options: use the MSB of the size, or introduce the third field
> > > for flags.
> > 
> > Well, it can be either recorded in the host variable tables (which contain
> > address and size pair, right), or in corresponding offloading device table
> > (which contains the pointer, something else?).
> 
> It contains a size too, which is checked in libgomp:
> 	  gomp_fatal ("Can't map target variables (size mismatch)");
> Yes, we can remove this check, and use second field in device table for flags.

Yeah, or e.g. just use MSB of that size (so check that either the size is
the same (then it is target to) or it is MSB | size (then it is target link).
Objects larger than half of the address space aren't really supportable
anyway.

	Jakub