[PATCH] D105648: [OpenMP] Support OpenMP 5.1 attributes

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman created this revision.
aaron.ballman added reviewers: ABataev, jdoerfert, erichkeane, bader, rsmith.
Herald added subscribers: dexonsmith, zzheng, guansong, yaxunl.
aaron.ballman requested review of this revision.
Herald added a subscriber: sstefan1.
Herald added a project: clang.

OpenMP 5.1 added support for writing OpenMP directives using `[[]]` syntax in addition to using `#pragma` and this introduces support for the new syntax.

In OpenMP, the attributes take one of two forms: `[[omp::directive(...)]]` or `[[omp::sequence(...)]]`. A `directive` attribute contains an OpenMP directive clause that is identical to the analogous `#pragma` syntax. A `sequence` attribute can contain either `sequence` or `directive` arguments and is used to ensure that the attributes are processed sequentially for situations where the order of the attributes matter (remember: https://eel.is/c++draft/dcl.attr.grammar#4.sentence-4).

The approach taken here is somewhat novel and deserves mention. We could refactor much of the OpenMP parsing logic to work for either pragma annotation tokens or for attribute clauses. It would be a fair amount of effort to share the logic for both, but it's certainly doable. However, the semantic attribute system is not designed to handle the arbitrarily complex arguments that OpenMP directives contain. Adding support to thread the novel parsed information until we can produce a semantic attribute would be considerably more effort. What's more, existing OpenMP constructs are not (often) represented as semantic attributes. So doing this through Attr.td would be a massive undertaking that would likely only benefit OpenMP and comes with additional risks. Rather than walk down that path, I am taking advantage of the fact that the syntax of the directives within the `directive` clause is identical to that of the `#pragma` form. Once the parser recognizes that we're processing an OpenMP attribute, it caches all of the directive argument tokens and then replays them as though the user wrote a pragma. This reuses the same OpenMP parsing and semantic logic directly, but does come with a risk if the OpenMP committee decides to purposefully diverge their pragma and attribute syntaxes. So, despite this being a novel approach that does token replay, I think it's actually a better approach than trying to do this through the declarative syntax in Attr.td.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D105648

Files:
  clang/docs/OpenMPSupport.rst
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/TokenKinds.def
  clang/include/clang/Parse/Parser.h
  clang/lib/Basic/Attributes.cpp
  clang/lib/Parse/ParseCXXInlineMethods.cpp
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Parse/ParseOpenMP.cpp
  clang/lib/Parse/ParseStmt.cpp
  clang/lib/Parse/Parser.cpp
  clang/test/OpenMP/allocate_codegen_attr.cpp
  clang/test/OpenMP/assumes_messages_attr.c
  clang/test/OpenMP/critical_codegen_attr.cpp
  clang/test/OpenMP/masked_messages_attr.cpp
  clang/test/OpenMP/openmp_attribute.cpp
  clang/test/OpenMP/openmp_attribute_parsing.cpp
  clang/test/OpenMP/target_map_names_attr.cpp
  clang/test/OpenMP/taskloop_reduction_messages_attr.cpp
  clang/test/OpenMP/teams_distribute_parallel_for_simd_num_teams_messages_attr.cpp
  clang/test/OpenMP/unroll_codegen_unroll_for_attr.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D105648.357288.patch
Type: text/x-patch
Size: 97179 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20210708/8a434b17/attachment-0001.bin>