[PATCH] D106509: [OpenMP][OpenACC] Implement `hold` map type modifier extension in Clang (1/2)

Joel E. Denny via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Jul 21 16:36:29 PDT 2021


jdenny created this revision.
jdenny added reviewers: ABataev, grokos, clementval, jdoerfert, RaviNarayanaswamy.
jdenny added projects: OpenMP, OpenACC.
Herald added subscribers: arphaman, guansong, yaxunl.
Herald added a reviewer: sscalpone.
jdenny requested review of this revision.
Herald added a subscriber: sstefan1.
Herald added a project: clang.

This patch implements Clang support for an original OpenMP extension
we have developed to support OpenACC: the `hold` map type modifier.
The next patch in this series implements OpenMP runtime support.

Consider the following example:

  #pragma omp target data map(hold, tofrom: x) // holds onto mapping of x
  {
    foo(); // might have map(delete: x)
    #pragma omp target map(present, alloc: x) // x is guaranteed to be present
    printf("%d\n", x); 
  }

The `hold` map type modifier above specifies that the `target data`
directive holds onto the mapping for `x` throughout the associated
region regardless of any `target exit data` directives executed during
the call to `foo`.  Thus, the presence assertion for `x` at the 
enclosed `target` construct cannot fail.

Justification for inclusion in Clang and LLVM's OpenMP runtime:

- The `hold` modifier supports OpenACC functionality (structured reference count) that cannot be achieved in standard OpenMP, as of 5.1.
- The runtime implementation for `hold` (next patch) will thus be used by Flang's OpenACC support.
- The Clang implementation for `hold` (this patch) as well as the runtime implementation are required for the Clang OpenACC support being developed as part of the ECP Clacc project, which translates OpenACC to OpenMP at the directive AST level.  These patches are the first step in upstreaming OpenACC functionality from Clacc.
- The Clang implementation for `hold` is also used by the tests in the runtime implementation.  Generally, a high-level syntax to express this feature facilitates discussion of the concept and makes tests more readable than low-level runtime calls can.
- OpenMP users might find the `hold` modifier useful, as in the above example.

See new documentation introduced by this patch in `openmp/docs` for 
more detail on the functionality of this extension and its 
relationship with OpenACC.

Questions:

- Clang currently doesn't support OpenMP 5.1 features unless `-fopenmp-version=51`.  Does it make sense to have an option to enable extensions?  Instead of a separate option, we could accept something like `-fopenmp-version=51,hold,foo`.
- In Clang diagnostics, this patch does not add `hold` to the list of acceptable map type modifiers because it's an extension.  Should it? If there were a command-line option to enable extensions, that would make the path clearer.
- This patch adds an "OpenMP Extensions" section to `clang/docs/OpenMPSupport.rst`.  However, the existing use of the word "extensions" in that document is confusing as it refers to standard features.  It should probably be replaced with "features". I'm considering that change for a parent patch.  Any objections?


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D106509

Files:
  clang/docs/OpenMPSupport.rst
  clang/include/clang/AST/OpenMPClause.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/OpenMPKinds.def
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/Parse/ParseOpenMP.cpp
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/OpenMP/target_ast_print.cpp
  clang/test/OpenMP/target_data_ast_print.cpp
  clang/test/OpenMP/target_data_map_codegen_hold.cpp
  clang/test/OpenMP/target_enter_data_map_messages.c
  clang/test/OpenMP/target_exit_data_map_messages.c
  clang/test/OpenMP/target_map_codegen_hold.cpp
  clang/test/OpenMP/target_map_messages.cpp
  openmp/docs/index.rst
  openmp/docs/openacc/OpenMPExtensions.rst
  openmp/docs/openacc/Overview.rst

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D106509.360522.patch
Type: text/x-patch
Size: 164506 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20210721/6d227500/attachment-0001.bin>


More information about the cfe-commits mailing list