On Mon, Jul 06, 2015 at 06:34:25PM +0300, Ilya Verbin wrote:
> On Thu, Jul 02, 2015 at 00:06:58 +0300, Ilya Verbin wrote:
> > On Tue, Jun 30, 2015 at 18:10:44 +0200, Jakub Jelinek wrote:
> > > The thing is whether it is actually a good idea to allocate the enter data
> > > allocated objects together.
> > > In OpenMP 4.0, generally objects would be allocated and deallocated at the
> > > same times, except for multiple host threads trying to map the same
> > > variables
> > > into the target. In OpenMP 4.1, due to enter data/exit data, they can be
> > > allocated and freed quite independently, and it is true that is the case
> > > even for target data, one can either target data, then target enter data
> > > to prevent something from being deallocated, then target data end freeing
> > > only parts, etc. So the question is if we think in real-world the
> > > allocation or deallocation will be usually together or not.
> >
> > IMHO, it's OK to allocate "target data" objects together and "target enter
> > data"
> > objects one by one. I've implemented this approach in the patch bellow.
> >
> > However, if someone writes a program like this:
> >
> > #pragma omp target data map(tofrom: small, arr[:big])
> > {
> > #pragma omp target enter data map(to: small)
> > }
> > do_a_lot_of_something ();
> > #pragma omp target exit data map(from: small)
> >
> > Big array will be deallocated on target only with 'small' at the end.
> > Is this acceptable?
>
> Ping?
I think it is.
> > The patch is not ready though, I don't know how to unmap GOMP_MAP_POINTER
> > vars.
> > In gomp_unmap_vars they're unmapped through tgt->list[], but in
> > gomp_exit_data
> > it's impossible to find such var in the splay tree, because hostaddr differs
> > from the address, used at mapping.
>
> I can keep a splay_tree_key of the GOMP_MAP_POINTER in the new field in
> target_mem_desc of the previous var (i.e. corresponding memory block).
> Or could you suggest a better approach?
What exactly do you have in mind here?
void foo (int *p)
{
#pragma omp enter data (to:p[10])
...
#pragma omp exit data (from:p[10])
}
where the latter will only deallocate &p[0] ... &p[9], but not &p?
I've asked for clarification in that case, but if it should deallocate (or
decrease the counter) for &p too, then I think this is something for the
frontends to handle during handling of array sections in map clause, or
during gimplification or omp lowering.
Jakub
