This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [gomp4.1 WIP] omp_target_* libgomp APIs
- From: Ilya Verbin <iverbin at gmail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Kirill Yukhin <kirill dot yukhin at gmail dot com>
- Date: Mon, 13 Jul 2015 18:15:45 +0300
- Subject: Re: [gomp4.1 WIP] omp_target_* libgomp APIs
- Authentication-results: sourceware.org; auth=none
- References: <20150709140657 dot GR10247 at tucnak dot redhat dot com> <20150713131729 dot GP1788 at tucnak dot redhat dot com> <20150713133833 dot GA56059 at msticlxl57 dot ims dot intel dot com> <20150713140306 dot GR1788 at tucnak dot redhat dot com>
On Mon, Jul 13, 2015 at 16:03:06 +0200, Jakub Jelinek wrote:
> On Mon, Jul 13, 2015 at 04:38:33PM +0300, Ilya Verbin wrote:
> > On Mon, Jul 13, 2015 at 15:17:29 +0200, Jakub Jelinek wrote:
> > > + k->refcount = INT_MAX;
> >
> > Shouldn't it be UINTPTR_MAX?
>
> Dunno if we can count on it being in stdint.h on all targets.
> Perhaps
> #define REFCOUNT_INFINITY (~(uintptr_t) 0)
> ?
Probably, I don't know.
> > > + /* FIXME: Support device-to-device somehow? */
> >
> > Should libgomp copy data device-host-device if device-device is not supported by
> > target? Current liboffloadmic doesn't support this. I'll find out if there are
> > any plans.
>
> There is also the option to spawn an offloaded function that will just call
> memcpy, or have such a function next to the main () of the program that we link
> in.
Do you mean the case when src_devicep == dst_devicep ? It's easy to support
this by adding new func into plugin, whithout any changes in liboffloadmic.
I thought about memcpy between different devices...
> Also, could you see if the 2 and 3 dimension memcpy_rect couldn't be handled
> more efficiently by liboffloadmic too?
> From what I can see, on the cuda side there is some cudaMemcpy2D and
> cudaMemcpy3D, though I admit I haven't studied in detail what exactly they
> do.
I'll try to find out.
-- Ilya