[Bug libgomp/110840] New: [OpenMP] Check whether device locking is really needed for bare memcopy to/from devices (omp_target_memcpy...)

[Bug libgomp/110840] New: [OpenMP] Check whether device locking is really needed for bare memcopy to/from devices (omp_target_memcpy...)

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110840

            Bug ID: 110840
           Summary: [OpenMP] Check whether device locking is really needed
                    for bare memcopy to/from devices
                    (omp_target_memcpy...)
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Keywords: missed-optimization, openacc, openmp
          Severity: normal
          Priority: P3
         Component: libgomp
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org
                CC: jakub at gcc dot gnu.org, tschwinge at gcc dot gnu.org
  Target Milestone: ---

See also PR110813 for a performance PR for omp_target_memcpy_rect

Thomas wrote in https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625670.html
>
> >      gomp_mutex_lock (&src_devicep->lock);
> > -  else if (dst_devicep)
> > +  if (lock_dst)
> >      gomp_mutex_lock (&dst_devicep->lock);
>
> (Pre-existing issue, and I've not myself tried to figure out the details
> at this time -- why do we actually lock the devices here, and in similar
> other places?)

 * * *

It seems as if for just copying memory to a fixed pointer, it should not be
needed - if the memory disappears, it will be a user problem. Or is there an
issue in terms of handling the context - like in CUDA's call to
nvptx_attach_host_thread_to_device ?

Pure memory copy without splay-tree lookups is in:

* omp_target_memcpy_copy
* omp_target_memcpy_rect_copy

 * * *

Besides pure memory copy, are there other places where the looking could be
removed? Or places were it is missing?