This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Offloading Support in libgomp
- From: Jakub Jelinek <jakub at redhat dot com>
- To: "Michael V. Zolotukhin" <michael dot v dot zolotukhin at gmail dot com>
- Cc: Kirill Yukhin <kirill dot yukhin at gmail dot com>, Richard Henderson <rth at redhat dot com>, GCC Development <gcc at gcc dot gnu dot org>, triegel at redhat dot com
- Date: Tue, 17 Sep 2013 14:29:27 +0200
- Subject: Re: [RFC] Offloading Support in libgomp
- Authentication-results: sourceware.org; auth=none
- References: <20130826115911 dot GA40923 at msticlxl57 dot ims dot intel dot com> <20130826125116 dot GE21876 at tucnak dot zalov dot cz> <20130826132936 dot GB40923 at msticlxl57 dot ims dot intel dot com> <20130826141117 dot GF21876 at tucnak dot zalov dot cz> <20130827112609 dot GA4093 at msticlxl57 dot ims dot intel dot com> <20130827113956 dot GH21876 at tucnak dot zalov dot cz> <20130827115538 dot GB4093 at msticlxl57 dot ims dot intel dot com> <20130913093417 dot GA30181 at msticlxl57 dot ims dot intel dot com> <20130916093549 dot GP1817 at tucnak dot redhat dot com> <20130917120454 dot GE60139 at msticlxl57 dot ims dot intel dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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