On Tue, 9 Jun 2020 12:41:21 +0200
Thomas Schwinge <tho...@codesourcery.com> wrote:
> Hi Julian!
>
> On 2020-06-05T21:31:08+0100, Julian Brown <jul...@codesourcery.com>
> wrote:
> >> For the OpenACC runtime API 'acc_attach' etc. routines they don't,
> >> so what's the conceptual reason that for the corresponding OpenACC
> >> directive variants, 'GOMP_MAP_ATTACH' etc. here participate in
> >> reference counting ('n->refcount++' above)? I understand OpenACC
> >> 'attach'/'detach' clauses to be simple "executable clauses", which
> >> just update some values somewhere (say, like
> >> 'GOMP_MAP_ALWAYS_POINTER'), but they don't alter any mapping state,
> >> thus wouldn't appear to need reference counting?
> >
> > IIUC, n->refcount is not directly the "structural reference count"
> > as seen at source level, but rather counts the number of
> > target_var_descs in the lists appended to each target_mem_desc --
> > and GOMP_MAP_ATTACH have variable entries in those lists.
>
> That may be OK if that's purely an implementation detail that isn't
> visible to the user, however:
>
> > That's not the case for the API
> > routines.
>
> As I had mentioned, the problem is: in contrast to 'acc_attach', an
> OpenACC 'enter data' directive with 'attach' clause currently uses
> this same reference-counted code path, and thus such an 'attach'
> without corresponding 'detach' inhibits unmapping; see
> 'libgomp.oacc-c-c++-common/mdc-refcount-1.c' in the attached patch
> "OpenACC 'attach'/'detach' has no business affecting user-visible
> reference counting".
Hmm, right. That's quite a problem from an implementation perspective:
the "attach" clause in the target_mem_desc's var list is what triggers
the "detach" operation (for structured data lifetimes). Having those
references "not count" is quite an ugly wrinkle.
I'll think about that some more...
> That patch seemed to be the logical next step then, to unify the code
> paths for 'acc_attach' and 'enter data' directive with 'attach' clause
> (which have to act in the same way). That's (conceptually) somewhat
> similar to what you had proposed as part of
> <b23ea71697f77d8214411a3e1348e9dee496e5a6.1590182783.git.julian@codesourcery.com">http://mid.mail-archive.com/b23ea71697f77d8214411a3e1348e9dee496e5a6.1590182783.git.julian@codesourcery.com>.
> (But all these things really need to be discussed individually...)
>
> However, that patch regresses
> 'libgomp.oacc-fortran/deep-copy-6-no_finalize.F90', and also the
> 'deep-copy-7b2f-2.c', and 'deep-copy-7cf.c' that I'm attaching here.
> I have not yet made an attempts to understand these regressions. It
> may be that a Detach Action actually effects an (attached) device
> pointer being copied back to the host, and then disturbing things --
> and if that, then it may be a bug in libgomp, or in the test case.
> ;-)
I haven't (even) quite absorbed what you are trying to test with the "no
finalize" version of the deep-copy-6.f90 test case... I probably need
to go back and re-read the spec. IIRC, my understanding was that
copying out a data item that still has multiple attachments would *not*
automatically perform a detachment. Thus, attaches & detaches have to
balance (at least without "finalize"). But maybe I was wrong about that!
Thanks,
Julian
