On Wed, 12 Nov 2014 11:06:26 +0100
Jakub Jelinek <ja...@redhat.com> wrote:

> On Tue, Nov 11, 2014 at 01:53:23PM +0000, Julian Brown wrote:
> > A few OpenMP tests fail with the new host_nonshm plugin (with
> > failures of the form "libgomp: Trying to update
> > [0x605820..0x605824) object that is not mapped"), probably because
> > of middle-end bugs. I haven't investigated those in detail.
> 
> Depends how exactly your host_nonshm plugin works.  A few tests in the
> testsuite use #pragma omp declare target variables, so if host_nonshm
> plugin is something like I had on the gomp-4_0-branch initially as
> hackish device 257, where code is run on the host, and map directives
> simply malloc/free host memory and memcpy stuff around, then without
> extra work the #pragma omp declare target variables indeed can't work.
> You'd either need to support a strange partially shared memory model,
> where #pragma omp declare target variables would be shared (you'd
> still need to populate the mapping data structures with those vars
> and identity map them), or not so conforming model where you'd map
> them on entering the target regions if they aren't mapped yet (the
> thing is that then if the variables are changed on the host in
> between the start of the program and the target region, you'd use the
> changed values instead the values they were originally assigned), or
> map them in some constructor (but, how would you know if a
> host_nonshm plugin is going to be used in the future).

Thanks for the review! I'll work on addressing your comments. Your
characterization of the host_nonshm plugin sounds accurate, but OOI,
what does the Intel MIC plugin do differently that means it is not
subject to the same problem with target variables?

> One can always use the intelmicemul plugin to test nonshared-memory
> stuff without any HW (provided the host is x86_64/i686), so do we
> really need host_nonshm plugin?

It might still be useful for testing (non-shm) OpenACC without
hardware, I guess (or for pedagogical purposes) -- perhaps we could
remove the TARGET_CAP_OPENMP_400 flag, if that's not expected to work.

Julian

Reply via email to