[all-commits] [llvm/llvm-project] 1e447d: [OpenMP] Introduce an environment variable to disa...

[Johannes Doerfert via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 1e447d03e2f634b7772b8f2c52a8a2cbafa51f19
      https://github.com/llvm/llvm-project/commit/1e447d03e2f634b7772b8f2c52a8a2cbafa51f19
  Author: Johannes Doerfert <johannes at jdoerfert.de>
  Date:   2022-01-19 (Wed, 19 Jan 2022)

  Changed paths:
    M openmp/docs/design/Runtimes.rst
    M openmp/libomptarget/include/device.h
    M openmp/libomptarget/src/device.cpp
    M openmp/libomptarget/src/omptarget.cpp
    M openmp/libomptarget/src/rtl.cpp

  Log Message:
  -----------
  [OpenMP] Introduce an environment variable to disable atomic map clauses

Atomic handling of map clauses was introduced to comply with the OpenMP
standard (see D104418). However, many apps won't need this feature which
can be costly in certain situations. To allow for applications to
opt-out we now introduce the `LIBOMPTARGET_MAP_FORCE_ATOMIC` environment
flag that voids the atomicity guarantee of the standard for map clauses
again, shifting the burden to the user.

This patch also de-duplicates the code that introduces the events used
to enforce atomicity as a cleanup.

Differential Revision: https://reviews.llvm.org/D117627


  Commit: b0789a1b12cd1d63fdc008e33399ba64a898c722
      https://github.com/llvm/llvm-project/commit/b0789a1b12cd1d63fdc008e33399ba64a898c722
  Author: Johannes Doerfert <johannes at jdoerfert.de>
  Date:   2022-01-19 (Wed, 19 Jan 2022)

  Changed paths:
    M openmp/libomptarget/include/device.h
    M openmp/libomptarget/src/api.cpp
    M openmp/libomptarget/src/device.cpp
    M openmp/libomptarget/src/omptarget.cpp

  Log Message:
  -----------
  [OpenMP] Avoid costly shadow map traversals whenever possible

In the OpenMC app we saw `omp target update` spending an awful lot of
time in the shadow map traversal without ever doing any update there.
There are two cases that allow us to avoid the traversal completely.
The simplest thing is that small updates cannot (reasonably) contain
an attached pointer part. The other case requires to track in the
mapping table if an entry might contain an attached pointer as part.
Given that we have a single location shadow map entries are created,
the latter is actually fairly easy as well.

Differential Revision: https://reviews.llvm.org/D113124


Compare: https://github.com/llvm/llvm-project/compare/eb675e972d74...b0789a1b12cd