[RFC] Offloading Support in libgomp

Jakub Jelinek jakub@redhat.com
Tue Sep 17 12:30:00 GMT 2013


On Tue, Sep 17, 2013 at 04:04:54PM +0400, Michael V. Zolotukhin wrote:
> > ... and the first GOMP_target,
> > GOMP_target_data or GOMP_target_update from a particular shared library or
> > binary (all of them will have __OPENMP_TARGET__ weak hidden symbol as one of
> > the arguments) offloads the embedded shared library into target (resp.
> > compiles HSAIL/PTX and uploads or whatever).
> What is that __OPENMP_TARGET__ argument?  Is it an address of section with
> target code or something like that?  I am not sure I am completely clear with
> this part.  (Please also find my other questions/comments below).

See http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00276.html

> > See above and my earlier mail why a name is a bad idea.  You will look up
> > the { fnaddr, fnaddr + 1 } address range in the target mapping structure
> > instead.
> So, fnaddr is the host function address, right?  Then we are looking for it in
> the splay tree and find the corresponding address on the target side, correct?
> What do we map for the functions?
> Also, AFAIK COI needs a name passed to it to run offloaded function, so we might
> want to keep the name anyway.

See above, names are just a bad idea.  You can just use some magic wrapper
name in the target binary (the one sitting in libgomp), to which you just
pass the pair of function address and it's argument and the named function
will just read the (target) function pointer and (target) pointer argument
from misc data block and tail call that function.
Looking at COI source, the function is:
COINATIVELIBEXPORT
void Foo (uint32_t         in_BufferCount,
          void**           in_ppBufferPointers,
          uint64_t*        in_pBufferLengths,
          void*            in_pMiscData,
          uint16_t         in_MiscDataLength,
          void*            in_pReturnValue,
          uint16_t         in_ReturnValueLength)
{
  ...
}
anyway, so wouldn't match very well the API we have right now (just one
.omp_target_s * argument).

> Yep, but again, this document was intended to describe decisions we've chosen
> for implementation of OpenMP4 offloading support.
> 
> In general, what do you think, is it worth maintaining such document (and
> probably later upload it as a wiki page) or we don't need it and it's better
> just be dropped?

I don't know, if it helps you to work on the implementation, maybe, but if
it gets stale quickly and won't match the actual implementation, it won't
help much.

	Jakub



More information about the Gcc mailing list