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.
I'm working on the implementation of OpenMP 5.1 feature `atomic compare`.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D100507
Adding features in OpenMP 5.1 specification, as documented in feature change history, to the 5.1 table. I alphabetized the rows of the table according to the category. For deprecating master construct, I just used 'other' as the category.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D90802
There are a few places with unexpected indents that trip over sphinx and
other syntax errors.
Also, the C++ syntax highlighting does not work for
class [[gsl::Owner(int)]] IntOwner {
Use a regular code:: block instead.
There are a few other warnings errors remaining, of the form
'Duplicate explicit target name: "cmdoption-clang--prefix"'. They seem
to be caused by the following
.. option:: -B<dir>, --prefix <arg>, --prefix=<arg>
I am no Restructured Text expert, but it seems like sphinx 1.8.5
tries to generate the same target for the --prefix <arg> and
--prefix=<arg>. This pops up in a lot of places and I am not sure how to
best resolve it
Reviewers: jfb, Bigcheese, dexonsmith, rjmccall
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D76534
Summary: This is updating the OpenMP status table. Cray has volunteered for `defaultmap` and supporting `in_reduction` on the `target` construct, so the status on those entries from was changed from "unclaimed". Also, a new entry was added for supporting non-contiguous arrays sections on the `target update` directive.
Reviewers: ABataev, hfinkel, jdoerfert, kkwli0
Reviewed By: ABataev
Subscribers: guansong, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69923
Removed the explicit list of supported features from OpenMP 5.0 and used
the reference to the table instead. Also, fixed info about constructs
that can be executed in SPMD mode, if and num_threads clauses do not
affect it anymore.
Michael Kruse