maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/lib/Parse/ParseOpenMP.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

4391 lines
158 KiB
C++
Raw Normal View History

OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 14:34:35 +08:00
//===--- ParseOpenMP.cpp - OpenMP directives parsing ----------------------===//
//
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2019-01-19 16:50:56 +08:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 14:34:35 +08:00
//
//===----------------------------------------------------------------------===//
/// \file
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// This file implements parsing of all OpenMP directives and clauses.
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 14:34:35 +08:00
///
//===----------------------------------------------------------------------===//
[OPENMP] Initial codegen for '#pragma omp parallel' llvm-svn: 208077
2014-05-06 18:08:46 +08:00
#include "clang/AST/ASTContext.h"
[OpenMP][NFC] Remove the need to include `OpenMPClause.h` See rational here: https://reviews.llvm.org/D76173#1922916 Time to compile Attr.h in isolation goes from 2.6s to 1.8s. Original patch by Johannes, plus some additions from Reid to fix some clang tooling targets. Effect on transitive includes is marginal, though: $ diff -u <(sort thedeps-before.txt) <(sort thedeps-after.txt) \ | grep '^[-+] ' | sort | uniq -c | sort -nr 104 - /usr/local/google/home/rnk/llvm-project/clang/include/clang/AST/OpenMPClause.h 87 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Frontend/OpenMP/OMPContext.h 19 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/ADT/SmallSet.h 19 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/ADT/SetVector.h 14 - /usr/include/c++/9/set ... Differential Revision: https://reviews.llvm.org/D76184
2020-04-04 03:35:30 +08:00
#include "clang/AST/OpenMPClause.h"
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
#include "clang/AST/StmtOpenMP.h"
[OPENMP50]Basic support for conditional lastprivate. Added parsing/sema checks for conditional lastprivates.
2019-12-21 00:04:57 +08:00
#include "clang/Basic/OpenMPKinds.h"
[OpenMP] `omp begin/end declare variant` - part 2, sema ("+CG") This is the second part loosely extracted from D71179 and cleaned up. This patch provides semantic analysis support for `omp begin/end declare variant`, mostly as defined in OpenMP technical report 8 (TR8) [0]. The sema handling makes code generation obsolete as we generate "the right" calls that can just be handled as usual. This handling also applies to the existing, albeit problematic, `omp declare variant support`. As a consequence a lot of unneeded code generation and complexity is removed. A major purpose of this patch is to provide proper `math.h`/`cmath` support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. The logic is as follows: If we have seen a `#pragma omp begin declare variant match(<SELECTOR>)` but not the corresponding `end declare variant`, and we find a function definition we will: 1) Create a function declaration for the definition we were about to generate. 2) Create a function definition but with a mangled name (according to `<SELECTOR>`). 3) Annotate the declaration with the `OMPDeclareVariantAttr`, the same one used already for `omp declare variant`, using and the mangled function definition as specialization for the context defined by `<SELECTOR>`. When a call is created we inspect it. If the target has an `OMPDeclareVariantAttr` attribute we try to specialize the call. To this end, all variants are checked, the best applicable one is picked and a new call to the specialization is created. The new call is used instead of the original one to the base function. To keep the AST printing and tooling possible we utilize the PseudoObjectExpr. The original call is the syntactic expression, the specialized call is the semantic expression. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim, aaron.ballman Subscribers: bollu, guansong, openmp-commits, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D75779
2020-02-26 06:04:06 +08:00
#include "clang/Basic/TargetInfo.h"
[OPENMP50]Add 'default' modifier in reduction clauses. Added full support for 'default' modifier in the reduction clauses.
2020-03-24 05:30:38 +08:00
#include "clang/Basic/TokenKinds.h"
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 14:34:35 +08:00
#include "clang/Parse/ParseDiagnostic.h"
OpenMP threadprivate with qualified names. llvm-svn: 181683
2013-05-13 12:18:18 +08:00
#include "clang/Parse/Parser.h"
Publish RAIIObjectsForParser.h for external usage. Some clients (eg the cling interpreter) need to recover their parser from errors. Patch by Axel Naumann (D31190)! llvm-svn: 298606
2017-03-23 23:11:07 +08:00
#include "clang/Parse/RAIIObjectsForParser.h"
OpenMP threadprivate with qualified names. llvm-svn: 181683
2013-05-13 12:18:18 +08:00
#include "clang/Sema/Scope.h"
#include "llvm/ADT/PointerIntPair.h"
[OpenMP] Add initial support for `omp [begin/end] assumes` The `assumes` directive is an OpenMP 5.1 feature that allows the user to provide assumptions to the optimizer. Assumptions can refer to directives (`absent` and `contains` clauses), expressions (`holds` clause), or generic properties (`no_openmp_routines`, `ext_ABCD`, ...). The `assumes` spelling is used for assumptions in the global scope while `assume` is used for executable contexts with an associated structured block. This patch only implements the global spellings. While clauses with arguments are "accepted" by the parser, they will simply be ignored for now. The implementation lowers the assumptions directly to the `AssumptionAttr`. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D91980
2020-11-24 01:48:59 +08:00
#include "llvm/ADT/StringSwitch.h"
[OPENMP50]Register vendor name only once in vendor context selector. No need to store multiple copies of the same vendor names in the context selector, keep only single copy. llvm-svn: 374363
2019-10-10 23:15:26 +08:00
#include "llvm/ADT/UniqueVector.h"
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
#include "llvm/Frontend/OpenMP/OMPContext.h"
Commit for http://reviews.llvm.org/D10765 for OpenMP 4 target data directive parsing and sema. This commit is on behalf of Kelvin Li. llvm-svn: 242785
2015-07-21 21:44:28 +08:00
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 14:34:35 +08:00
using namespace clang;
[OpenMP][NFCI] Introduce llvm/IR/OpenMPConstants.h Summary: The new OpenMPConstants.h is a location for all OpenMP related constants (and helpers) to live. This patch moves the directives there (the enum OpenMPDirectiveKind) and rewires Clang to use the new location. Initially part of D69785. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: jholewinski, ppenzin, penzn, llvm-commits, cfe-commits, jfb, guansong, bollu, hiraditya, mgorny Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D69853
2019-11-05 12:00:49 +08:00
using namespace llvm::omp;
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 14:34:35 +08:00
//===----------------------------------------------------------------------===//
// OpenMP declarative directives.
//===----------------------------------------------------------------------===//
[OPENMP] NFC rewrite ParseOpenMPDirectiveKind New implementation is easier to read and extend. Differential Revision: http://reviews.llvm.org/D17197 llvm-svn: 260811
2016-02-13 14:53:38 +08:00
namespace {
enum OpenMPDirectiveKindEx {
[openmp] Base of tablegen generated OpenMP common declaration Summary: As discussed previously when landing patch for OpenMP in Flang, the idea is to share common part of the OpenMP declaration between the different Frontend. While doing this it was thought that moving to tablegen instead of Macros will also give a cleaner and more powerful way of generating these declaration. This first part of a future series of patches is setting up the base .td file for DirectiveLanguage as well as the OpenMP version of it. The base file is meant to be used by other directive language such as OpenACC. In this first patch, the Directive and Clause enums are generated with tablegen instead of the macros on OMPConstants.h. The next pacth will extend this to other enum and move the Flang frontend to use it. Reviewers: jdoerfert, DavidTruby, fghanim, ABataev, jdenny, hfinkel, jhuber6, kiranchandramohan, kiranktp Reviewed By: jdoerfert, jdenny Subscribers: arphaman, martong, cfe-commits, mgorny, yaxunl, hiraditya, guansong, jfb, sstefan1, aaron.ballman, llvm-commits Tags: #llvm, #openmp, #clang Differential Revision: https://reviews.llvm.org/D81736
2020-06-23 21:29:50 +08:00
OMPD_cancellation = llvm::omp::Directive_enumSize + 1,
[OPENMP] NFC rewrite ParseOpenMPDirectiveKind New implementation is easier to read and extend. Differential Revision: http://reviews.llvm.org/D17197 llvm-svn: 260811
2016-02-13 14:53:38 +08:00
OMPD_data,
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
OMPD_declare,
[OPENMP] Parsing and Sema support for 'omp declare target' directive Add parsing, sema analysis for 'declare target' construct for OpenMP 4.0 (4.5 support will be added in separate patch). The declare target directive specifies that variables, functions (C, C++ and Fortran), and subroutines (Fortran) are mapped to a device. The declare target directive is a declarative directive. In Clang declare target is implemented as implicit attribute for the declaration. The syntax of the declare target directive is as follows: #pragma omp declare target declarations-definition-seq #pragma omp end declare target Based on patch from Michael Wong http://reviews.llvm.org/D15321 llvm-svn: 265530
2016-04-06 19:38:59 +08:00
OMPD_end,
OMPD_end_declare,
[OPENMP] NFC rewrite ParseOpenMPDirectiveKind New implementation is easier to read and extend. Differential Revision: http://reviews.llvm.org/D17197 llvm-svn: 260811
2016-02-13 14:53:38 +08:00
OMPD_enter,
OMPD_exit,
OMPD_point,
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
OMPD_reduction,
[OPENMP] NFC rewrite ParseOpenMPDirectiveKind New implementation is easier to read and extend. Differential Revision: http://reviews.llvm.org/D17197 llvm-svn: 260811
2016-02-13 14:53:38 +08:00
OMPD_target_enter,
[OpenMP] Parsing and sema support for target update directive Summary: This patch is to add parsing and sema support for `target update` directive. Support for the `to` and `from` clauses will be added by a different patch. This patch also adds support for other clauses that are already implemented upstream and apply to `target update`, e.g. `device` and `if`. This patch is based on the original post by Kelvin Li. Reviewers: hfinkel, carlo.bertolli, kkwli0, arpith-jacob, ABataev Subscribers: caomhin, cfe-commits Differential Revision: http://reviews.llvm.org/D15944 llvm-svn: 270878
2016-05-27 01:30:50 +08:00
OMPD_target_exit,
OMPD_update,
[OpenMP] Sema and parsing for 'teams distribute parallel for simd' pragma This patch is to implement sema and parsing for 'teams distribute parallel for simd' pragma. Differential Revision: https://reviews.llvm.org/D27084 llvm-svn: 288294
2016-12-01 07:51:03 +08:00
OMPD_distribute_parallel,
[OpenMP] Sema and parsing for 'target teams distribute parallel for’ pragma This patch is to implement sema and parsing for 'target teams distribute parallel for’ pragma. Differential Revision: https://reviews.llvm.org/D28160 llvm-svn: 290725
2016-12-30 06:16:30 +08:00
OMPD_teams_distribute_parallel,
[OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive. This patch implements parsing and sema for "omp declare mapper" directive. User defined mapper, i.e., declare mapper directive, is a new feature in OpenMP 5.0. It is introduced to extend existing map clauses for the purpose of simplifying the copy of complex data structures between host and device (i.e., deep copy). An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(struct S s) map(s, s.d[0:s.len]) // Memory region that d points to is also mapped using this mapper. Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D56326 llvm-svn: 352906
2019-02-02 04:25:04 +08:00
OMPD_target_teams_distribute_parallel,
OMPD_mapper,
[OPENMP5.0]Add basic support for declare variant directive. Added basic support for declare variant directive and its match clause with user context selector. llvm-svn: 371892
2019-09-14 04:18:17 +08:00
OMPD_variant,
[OpenMP] `omp begin/end declare variant` - part 1, parsing This is the first part extracted from D71179 and cleaned up. This patch provides parsing support for `omp begin/end declare variant`, as defined in OpenMP technical report 8 (TR8) [0]. A major purpose of this patch is to provide proper math.h/cmath support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D74941
2020-02-21 09:50:47 +08:00
OMPD_begin,
OMPD_begin_declare,
[OPENMP] NFC rewrite ParseOpenMPDirectiveKind New implementation is easier to read and extend. Differential Revision: http://reviews.llvm.org/D17197 llvm-svn: 260811
2016-02-13 14:53:38 +08:00
};
[OpenMP] Parse+Sema for '#pragma omp declare target' syntax version 4.5 Support OpenMP version 4.5 syntax for #pragma omp declare target. Syntax: #pragma omp declare target (extended-list) new-line or #pragma omp declare target clause[ [,] clause ... ] new-line Where clause is one of the following: to(extended-list) link(list) Differential Revision: http://reviews.llvm.org/D20011 llvm-svn: 268925
2016-05-09 22:59:13 +08:00
[OpenMP][NFCI] Introduce llvm/IR/OpenMPConstants.h Summary: The new OpenMPConstants.h is a location for all OpenMP related constants (and helpers) to live. This patch moves the directives there (the enum OpenMPDirectiveKind) and rewires Clang to use the new location. Initially part of D69785. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: jholewinski, ppenzin, penzn, llvm-commits, cfe-commits, jfb, guansong, bollu, hiraditya, mgorny Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D69853
2019-11-05 12:00:49 +08:00
// Helper to unify the enum class OpenMPDirectiveKind with its extension
// the OpenMPDirectiveKindEx enum which allows to use them together as if they
// are unsigned values.
struct OpenMPDirectiveKindExWrapper {
OpenMPDirectiveKindExWrapper(unsigned Value) : Value(Value) {}
OpenMPDirectiveKindExWrapper(OpenMPDirectiveKind DK) : Value(unsigned(DK)) {}
Make LLVM build in C++20 mode Part of the <=> changes in C++20 make certain patterns of writing equality operators ambiguous with themselves (sorry!). This patch goes through and adjusts all the comparison operators such that they should work in both C++17 and C++20 modes. It also makes two other small C++20-specific changes (adding a constructor to a type that cases to be an aggregate, and adding casts from u8 literals which no longer have type const char*). There were four categories of errors that this review fixes. Here are canonical examples of them, ordered from most to least common: // 1) Missing const namespace missing_const { struct A { #ifndef FIXED bool operator==(A const&); #else bool operator==(A const&) const; #endif }; bool a = A{} == A{}; // error } // 2) Type mismatch on CRTP namespace crtp_mismatch { template <typename Derived> struct Base { #ifndef FIXED bool operator==(Derived const&) const; #else // in one case changed to taking Base const& friend bool operator==(Derived const&, Derived const&); #endif }; struct D : Base<D> { }; bool b = D{} == D{}; // error } // 3) iterator/const_iterator with only mixed comparison namespace iter_const_iter { template <bool Const> struct iterator { using const_iterator = iterator<true>; iterator(); template <bool B, std::enable_if_t<(Const && !B), int> = 0> iterator(iterator<B> const&); #ifndef FIXED bool operator==(const_iterator const&) const; #else friend bool operator==(iterator const&, iterator const&); #endif }; bool c = iterator<false>{} == iterator<false>{} // error || iterator<false>{} == iterator<true>{} || iterator<true>{} == iterator<false>{} || iterator<true>{} == iterator<true>{}; } // 4) Same-type comparison but only have mixed-type operator namespace ambiguous_choice { enum Color { Red }; struct C { C(); C(Color); operator Color() const; bool operator==(Color) const; friend bool operator==(C, C); }; bool c = C{} == C{}; // error bool d = C{} == Red; } Differential revision: https://reviews.llvm.org/D78938
2020-12-17 18:41:35 +08:00
bool operator==(OpenMPDirectiveKindExWrapper V) const {
return Value == V.Value;
}
bool operator!=(OpenMPDirectiveKindExWrapper V) const {
return Value != V.Value;
}
[OpenMP][NFCI] Introduce llvm/IR/OpenMPConstants.h Summary: The new OpenMPConstants.h is a location for all OpenMP related constants (and helpers) to live. This patch moves the directives there (the enum OpenMPDirectiveKind) and rewires Clang to use the new location. Initially part of D69785. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: jholewinski, ppenzin, penzn, llvm-commits, cfe-commits, jfb, guansong, bollu, hiraditya, mgorny Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D69853
2019-11-05 12:00:49 +08:00
bool operator==(OpenMPDirectiveKind V) const { return Value == unsigned(V); }
bool operator!=(OpenMPDirectiveKind V) const { return Value != unsigned(V); }
bool operator<(OpenMPDirectiveKind V) const { return Value < unsigned(V); }
operator unsigned() const { return Value; }
operator OpenMPDirectiveKind() const { return OpenMPDirectiveKind(Value); }
unsigned Value;
};
[OPENMP 5.0]Add initial support for 'allocate' directive. Added parsing/sema analysis/serialization/deserialization support for 'allocate' directive. llvm-svn: 355614
2019-03-08 01:54:44 +08:00
class DeclDirectiveListParserHelper final {
[OpenMP] Parse+Sema for '#pragma omp declare target' syntax version 4.5 Support OpenMP version 4.5 syntax for #pragma omp declare target. Syntax: #pragma omp declare target (extended-list) new-line or #pragma omp declare target clause[ [,] clause ... ] new-line Where clause is one of the following: to(extended-list) link(list) Differential Revision: http://reviews.llvm.org/D20011 llvm-svn: 268925
2016-05-09 22:59:13 +08:00
SmallVector<Expr *, 4> Identifiers;
Parser *P;
[OPENMP 5.0]Add initial support for 'allocate' directive. Added parsing/sema analysis/serialization/deserialization support for 'allocate' directive. llvm-svn: 355614
2019-03-08 01:54:44 +08:00
OpenMPDirectiveKind Kind;
[OpenMP] Parse+Sema for '#pragma omp declare target' syntax version 4.5 Support OpenMP version 4.5 syntax for #pragma omp declare target. Syntax: #pragma omp declare target (extended-list) new-line or #pragma omp declare target clause[ [,] clause ... ] new-line Where clause is one of the following: to(extended-list) link(list) Differential Revision: http://reviews.llvm.org/D20011 llvm-svn: 268925
2016-05-09 22:59:13 +08:00
public:
[OPENMP 5.0]Add initial support for 'allocate' directive. Added parsing/sema analysis/serialization/deserialization support for 'allocate' directive. llvm-svn: 355614
2019-03-08 01:54:44 +08:00
DeclDirectiveListParserHelper(Parser *P, OpenMPDirectiveKind Kind)
: P(P), Kind(Kind) {}
[OpenMP] Parse+Sema for '#pragma omp declare target' syntax version 4.5 Support OpenMP version 4.5 syntax for #pragma omp declare target. Syntax: #pragma omp declare target (extended-list) new-line or #pragma omp declare target clause[ [,] clause ... ] new-line Where clause is one of the following: to(extended-list) link(list) Differential Revision: http://reviews.llvm.org/D20011 llvm-svn: 268925
2016-05-09 22:59:13 +08:00
void operator()(CXXScopeSpec &SS, DeclarationNameInfo NameInfo) {
[OPENMP 5.0]Add initial support for 'allocate' directive. Added parsing/sema analysis/serialization/deserialization support for 'allocate' directive. llvm-svn: 355614
2019-03-08 01:54:44 +08:00
ExprResult Res = P->getActions().ActOnOpenMPIdExpression(
P->getCurScope(), SS, NameInfo, Kind);
[OpenMP] Parse+Sema for '#pragma omp declare target' syntax version 4.5 Support OpenMP version 4.5 syntax for #pragma omp declare target. Syntax: #pragma omp declare target (extended-list) new-line or #pragma omp declare target clause[ [,] clause ... ] new-line Where clause is one of the following: to(extended-list) link(list) Differential Revision: http://reviews.llvm.org/D20011 llvm-svn: 268925
2016-05-09 22:59:13 +08:00
if (Res.isUsable())
Identifiers.push_back(Res.get());
}
llvm::ArrayRef<Expr *> getIdentifiers() const { return Identifiers; }
};
[OPENMP] NFC rewrite ParseOpenMPDirectiveKind New implementation is easier to read and extend. Differential Revision: http://reviews.llvm.org/D17197 llvm-svn: 260811
2016-02-13 14:53:38 +08:00
} // namespace
// Map token string to extended OMP token kind that are
// OpenMPDirectiveKind + OpenMPDirectiveKindEx.
static unsigned getOpenMPDirectiveKindEx(StringRef S) {
[OpenMP][NFCI] Introduce llvm/IR/OpenMPConstants.h Summary: The new OpenMPConstants.h is a location for all OpenMP related constants (and helpers) to live. This patch moves the directives there (the enum OpenMPDirectiveKind) and rewires Clang to use the new location. Initially part of D69785. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: jholewinski, ppenzin, penzn, llvm-commits, cfe-commits, jfb, guansong, bollu, hiraditya, mgorny Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D69853
2019-11-05 12:00:49 +08:00
OpenMPDirectiveKindExWrapper DKind = getOpenMPDirectiveKind(S);
[OPENMP] NFC rewrite ParseOpenMPDirectiveKind New implementation is easier to read and extend. Differential Revision: http://reviews.llvm.org/D17197 llvm-svn: 260811
2016-02-13 14:53:38 +08:00
if (DKind != OMPD_unknown)
return DKind;
[OpenMP][NFCI] Introduce llvm/IR/OpenMPConstants.h Summary: The new OpenMPConstants.h is a location for all OpenMP related constants (and helpers) to live. This patch moves the directives there (the enum OpenMPDirectiveKind) and rewires Clang to use the new location. Initially part of D69785. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: jholewinski, ppenzin, penzn, llvm-commits, cfe-commits, jfb, guansong, bollu, hiraditya, mgorny Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D69853
2019-11-05 12:00:49 +08:00
return llvm::StringSwitch<OpenMPDirectiveKindExWrapper>(S)
[OPENMP] NFC rewrite ParseOpenMPDirectiveKind New implementation is easier to read and extend. Differential Revision: http://reviews.llvm.org/D17197 llvm-svn: 260811
2016-02-13 14:53:38 +08:00
.Case("cancellation", OMPD_cancellation)
.Case("data", OMPD_data)
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
.Case("declare", OMPD_declare)
[OPENMP] Parsing and Sema support for 'omp declare target' directive Add parsing, sema analysis for 'declare target' construct for OpenMP 4.0 (4.5 support will be added in separate patch). The declare target directive specifies that variables, functions (C, C++ and Fortran), and subroutines (Fortran) are mapped to a device. The declare target directive is a declarative directive. In Clang declare target is implemented as implicit attribute for the declaration. The syntax of the declare target directive is as follows: #pragma omp declare target declarations-definition-seq #pragma omp end declare target Based on patch from Michael Wong http://reviews.llvm.org/D15321 llvm-svn: 265530
2016-04-06 19:38:59 +08:00
.Case("end", OMPD_end)
[OPENMP] NFC rewrite ParseOpenMPDirectiveKind New implementation is easier to read and extend. Differential Revision: http://reviews.llvm.org/D17197 llvm-svn: 260811
2016-02-13 14:53:38 +08:00
.Case("enter", OMPD_enter)
.Case("exit", OMPD_exit)
.Case("point", OMPD_point)
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
.Case("reduction", OMPD_reduction)
[OpenMP] Parsing and sema support for target update directive Summary: This patch is to add parsing and sema support for `target update` directive. Support for the `to` and `from` clauses will be added by a different patch. This patch also adds support for other clauses that are already implemented upstream and apply to `target update`, e.g. `device` and `if`. This patch is based on the original post by Kelvin Li. Reviewers: hfinkel, carlo.bertolli, kkwli0, arpith-jacob, ABataev Subscribers: caomhin, cfe-commits Differential Revision: http://reviews.llvm.org/D15944 llvm-svn: 270878
2016-05-27 01:30:50 +08:00
.Case("update", OMPD_update)
[OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive. This patch implements parsing and sema for "omp declare mapper" directive. User defined mapper, i.e., declare mapper directive, is a new feature in OpenMP 5.0. It is introduced to extend existing map clauses for the purpose of simplifying the copy of complex data structures between host and device (i.e., deep copy). An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(struct S s) map(s, s.d[0:s.len]) // Memory region that d points to is also mapped using this mapper. Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D56326 llvm-svn: 352906
2019-02-02 04:25:04 +08:00
.Case("mapper", OMPD_mapper)
[OPENMP5.0]Add basic support for declare variant directive. Added basic support for declare variant directive and its match clause with user context selector. llvm-svn: 371892
2019-09-14 04:18:17 +08:00
.Case("variant", OMPD_variant)
[OpenMP] `omp begin/end declare variant` - part 1, parsing This is the first part extracted from D71179 and cleaned up. This patch provides parsing support for `omp begin/end declare variant`, as defined in OpenMP technical report 8 (TR8) [0]. A major purpose of this patch is to provide proper math.h/cmath support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D74941
2020-02-21 09:50:47 +08:00
.Case("begin", OMPD_begin)
[OPENMP] NFC rewrite ParseOpenMPDirectiveKind New implementation is easier to read and extend. Differential Revision: http://reviews.llvm.org/D17197 llvm-svn: 260811
2016-02-13 14:53:38 +08:00
.Default(OMPD_unknown);
}
[OpenMP][NFCI] Introduce llvm/IR/OpenMPConstants.h Summary: The new OpenMPConstants.h is a location for all OpenMP related constants (and helpers) to live. This patch moves the directives there (the enum OpenMPDirectiveKind) and rewires Clang to use the new location. Initially part of D69785. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: jholewinski, ppenzin, penzn, llvm-commits, cfe-commits, jfb, guansong, bollu, hiraditya, mgorny Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D69853
2019-11-05 12:00:49 +08:00
static OpenMPDirectiveKindExWrapper parseOpenMPDirectiveKind(Parser &P) {
Parsing/Sema of directive omp for simd llvm-svn: 218029
2014-09-18 13:12:34 +08:00
// Array of foldings: F[i][0] F[i][1] ===> F[i][2].
// E.g.: OMPD_for OMPD_simd ===> OMPD_for_simd
// TODO: add other combined directives in topological order.
[OpenMP][NFCI] Introduce llvm/IR/OpenMPConstants.h Summary: The new OpenMPConstants.h is a location for all OpenMP related constants (and helpers) to live. This patch moves the directives there (the enum OpenMPDirectiveKind) and rewires Clang to use the new location. Initially part of D69785. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: jholewinski, ppenzin, penzn, llvm-commits, cfe-commits, jfb, guansong, bollu, hiraditya, mgorny Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D69853
2019-11-05 12:00:49 +08:00
static const OpenMPDirectiveKindExWrapper F[][3] = {
[OpenMP] `omp begin/end declare variant` - part 1, parsing This is the first part extracted from D71179 and cleaned up. This patch provides parsing support for `omp begin/end declare variant`, as defined in OpenMP technical report 8 (TR8) [0]. A major purpose of this patch is to provide proper math.h/cmath support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D74941
2020-02-21 09:50:47 +08:00
{OMPD_begin, OMPD_declare, OMPD_begin_declare},
[OpenMP] Add initial support for `omp [begin/end] assumes` The `assumes` directive is an OpenMP 5.1 feature that allows the user to provide assumptions to the optimizer. Assumptions can refer to directives (`absent` and `contains` clauses), expressions (`holds` clause), or generic properties (`no_openmp_routines`, `ext_ABCD`, ...). The `assumes` spelling is used for assumptions in the global scope while `assume` is used for executable contexts with an associated structured block. This patch only implements the global spellings. While clauses with arguments are "accepted" by the parser, they will simply be ignored for now. The implementation lowers the assumptions directly to the `AssumptionAttr`. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D91980
2020-11-24 01:48:59 +08:00
{OMPD_begin, OMPD_assumes, OMPD_begin_assumes},
[OpenMP] `omp begin/end declare variant` - part 1, parsing This is the first part extracted from D71179 and cleaned up. This patch provides parsing support for `omp begin/end declare variant`, as defined in OpenMP technical report 8 (TR8) [0]. A major purpose of this patch is to provide proper math.h/cmath support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D74941
2020-02-21 09:50:47 +08:00
{OMPD_end, OMPD_declare, OMPD_end_declare},
[OpenMP] Add initial support for `omp [begin/end] assumes` The `assumes` directive is an OpenMP 5.1 feature that allows the user to provide assumptions to the optimizer. Assumptions can refer to directives (`absent` and `contains` clauses), expressions (`holds` clause), or generic properties (`no_openmp_routines`, `ext_ABCD`, ...). The `assumes` spelling is used for assumptions in the global scope while `assume` is used for executable contexts with an associated structured block. This patch only implements the global spellings. While clauses with arguments are "accepted" by the parser, they will simply be ignored for now. The implementation lowers the assumptions directly to the `AssumptionAttr`. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D91980
2020-11-24 01:48:59 +08:00
{OMPD_end, OMPD_assumes, OMPD_end_assumes},
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-24 03:53:05 +08:00
{OMPD_cancellation, OMPD_point, OMPD_cancellation_point},
{OMPD_declare, OMPD_reduction, OMPD_declare_reduction},
[OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive. This patch implements parsing and sema for "omp declare mapper" directive. User defined mapper, i.e., declare mapper directive, is a new feature in OpenMP 5.0. It is introduced to extend existing map clauses for the purpose of simplifying the copy of complex data structures between host and device (i.e., deep copy). An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(struct S s) map(s, s.d[0:s.len]) // Memory region that d points to is also mapped using this mapper. Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D56326 llvm-svn: 352906
2019-02-02 04:25:04 +08:00
{OMPD_declare, OMPD_mapper, OMPD_declare_mapper},
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-24 03:53:05 +08:00
{OMPD_declare, OMPD_simd, OMPD_declare_simd},
{OMPD_declare, OMPD_target, OMPD_declare_target},
[OPENMP5.0]Add basic support for declare variant directive. Added basic support for declare variant directive and its match clause with user context selector. llvm-svn: 371892
2019-09-14 04:18:17 +08:00
{OMPD_declare, OMPD_variant, OMPD_declare_variant},
[OpenMP] Overhaul `declare target` handling This patch fixes various issues with our prior `declare target` handling and extends it to support `omp begin declare target` as well. This started with PR49649 in mind, trying to provide a way for users to avoid the "ref" global use introduced for globals with internal linkage. From there it went down the rabbit hole, e.g., all variables, even `nohost` ones, were emitted into the device code so it was impossible to determine if "ref" was needed late in the game (based on the name only). To make it really useful, `begin declare target` was needed as it can carry the `device_type`. Not emitting variables eagerly had a ripple effect. Finally, the precedence of the (explicit) declare target list items needed to be taken into account, that meant we cannot just look for any declare target attribute to make a decision. This caused the handling of functions to require fixup as well. I tried to clean up things while I was at it, e.g., we should not "parse declarations and defintions" as part of OpenMP parsing, this will always break at some point. Instead, we keep track what region we are in and act on definitions and declarations instead, this is what we do for declare variant and other begin/end directives already. Highlights: - new diagnosis for restrictions specificed in the standard, - delayed emission of globals not mentioned in an explicit list of a declare target, - omission of `nohost` globals on the host and `host` globals on the device, - no explicit parsing of declarations in-between `omp [begin] declare variant` and the corresponding end anymore, regular parsing instead, - precedence for explicit mentions in `declare target` lists over implicit mentions in the declaration-definition-seq, and - `omp allocate` declarations will now replace an earlier emitted global, if necessary. --- Notes: The patch is larger than I hoped but it turns out that most changes do on their own lead to "inconsistent states", which seem less desirable overall. After working through this I feel the standard should remove the explicit declare target forms as the delayed emission is horrible. That said, while we delay things anyway, it seems to me we check too often for the current status even though that is often not sufficient to act upon. There seems to be a lot of duplication that can probably be trimmed down. Eagerly emitting some things seems pretty weak as an argument to keep so much logic around. --- Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D101030
2021-04-22 13:57:28 +08:00
{OMPD_begin_declare, OMPD_target, OMPD_begin_declare_target},
[OpenMP] `omp begin/end declare variant` - part 1, parsing This is the first part extracted from D71179 and cleaned up. This patch provides parsing support for `omp begin/end declare variant`, as defined in OpenMP technical report 8 (TR8) [0]. A major purpose of this patch is to provide proper math.h/cmath support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D74941
2020-02-21 09:50:47 +08:00
{OMPD_begin_declare, OMPD_variant, OMPD_begin_declare_variant},
{OMPD_end_declare, OMPD_variant, OMPD_end_declare_variant},
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-24 03:53:05 +08:00
{OMPD_distribute, OMPD_parallel, OMPD_distribute_parallel},
{OMPD_distribute_parallel, OMPD_for, OMPD_distribute_parallel_for},
{OMPD_distribute_parallel_for, OMPD_simd,
OMPD_distribute_parallel_for_simd},
{OMPD_distribute, OMPD_simd, OMPD_distribute_simd},
{OMPD_end_declare, OMPD_target, OMPD_end_declare_target},
{OMPD_target, OMPD_data, OMPD_target_data},
{OMPD_target, OMPD_enter, OMPD_target_enter},
{OMPD_target, OMPD_exit, OMPD_target_exit},
{OMPD_target, OMPD_update, OMPD_target_update},
{OMPD_target_enter, OMPD_data, OMPD_target_enter_data},
{OMPD_target_exit, OMPD_data, OMPD_target_exit_data},
{OMPD_for, OMPD_simd, OMPD_for_simd},
{OMPD_parallel, OMPD_for, OMPD_parallel_for},
{OMPD_parallel_for, OMPD_simd, OMPD_parallel_for_simd},
{OMPD_parallel, OMPD_sections, OMPD_parallel_sections},
{OMPD_taskloop, OMPD_simd, OMPD_taskloop_simd},
{OMPD_target, OMPD_parallel, OMPD_target_parallel},
{OMPD_target, OMPD_simd, OMPD_target_simd},
{OMPD_target_parallel, OMPD_for, OMPD_target_parallel_for},
{OMPD_target_parallel_for, OMPD_simd, OMPD_target_parallel_for_simd},
{OMPD_teams, OMPD_distribute, OMPD_teams_distribute},
{OMPD_teams_distribute, OMPD_simd, OMPD_teams_distribute_simd},
{OMPD_teams_distribute, OMPD_parallel, OMPD_teams_distribute_parallel},
{OMPD_teams_distribute_parallel, OMPD_for,
OMPD_teams_distribute_parallel_for},
{OMPD_teams_distribute_parallel_for, OMPD_simd,
OMPD_teams_distribute_parallel_for_simd},
{OMPD_target, OMPD_teams, OMPD_target_teams},
{OMPD_target_teams, OMPD_distribute, OMPD_target_teams_distribute},
{OMPD_target_teams_distribute, OMPD_parallel,
OMPD_target_teams_distribute_parallel},
{OMPD_target_teams_distribute, OMPD_simd,
OMPD_target_teams_distribute_simd},
{OMPD_target_teams_distribute_parallel, OMPD_for,
OMPD_target_teams_distribute_parallel_for},
{OMPD_target_teams_distribute_parallel_for, OMPD_simd,
[OPENMP50]Support for 'master taskloop' directive. Added full support for master taskloop directive. llvm-svn: 374437
2019-10-11 04:13:02 +08:00
OMPD_target_teams_distribute_parallel_for_simd},
[OPENMP50]Add support for 'parallel master taskloop' construct. Added parsing/sema/codegen support for 'parallel master taskloop' constructs. Some of the clauses, like 'grainsize', 'num_tasks', 'final' and 'priority' are not supported in full, only constant expressions can be used currently in these clauses. llvm-svn: 374791
2019-10-15 01:17:41 +08:00
{OMPD_master, OMPD_taskloop, OMPD_master_taskloop},
[OPENMP50]Add support for master taskloop simd. Added trsing/semantics/codegen for combined construct master taskloop simd. llvm-svn: 375255
2019-10-19 00:47:35 +08:00
{OMPD_master_taskloop, OMPD_simd, OMPD_master_taskloop_simd},
[OPENMP50]Add support for 'parallel master taskloop' construct. Added parsing/sema/codegen support for 'parallel master taskloop' constructs. Some of the clauses, like 'grainsize', 'num_tasks', 'final' and 'priority' are not supported in full, only constant expressions can be used currently in these clauses. llvm-svn: 374791
2019-10-15 01:17:41 +08:00
{OMPD_parallel, OMPD_master, OMPD_parallel_master},
[OPENMP50]Add support for parallel master taskloop simd directive. Added full support for parallel master taskloop simd directive.
2019-10-25 22:27:13 +08:00
{OMPD_parallel_master, OMPD_taskloop, OMPD_parallel_master_taskloop},
{OMPD_parallel_master_taskloop, OMPD_simd,
OMPD_parallel_master_taskloop_simd}};
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
enum { CancellationPoint = 0, DeclareReduction = 1, TargetData = 2 };
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-24 03:53:05 +08:00
Token Tok = P.getCurToken();
[OpenMP][NFCI] Introduce llvm/IR/OpenMPConstants.h Summary: The new OpenMPConstants.h is a location for all OpenMP related constants (and helpers) to live. This patch moves the directives there (the enum OpenMPDirectiveKind) and rewires Clang to use the new location. Initially part of D69785. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: jholewinski, ppenzin, penzn, llvm-commits, cfe-commits, jfb, guansong, bollu, hiraditya, mgorny Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D69853
2019-11-05 12:00:49 +08:00
OpenMPDirectiveKindExWrapper DKind =
[OPENMP] Added initial support for 'omp parallel for'. llvm-svn: 212453
2014-07-07 21:01:15 +08:00
Tok.isAnnotation()
[OPENMP] NFC rewrite ParseOpenMPDirectiveKind New implementation is easier to read and extend. Differential Revision: http://reviews.llvm.org/D17197 llvm-svn: 260811
2016-02-13 14:53:38 +08:00
? static_cast<unsigned>(OMPD_unknown)
: getOpenMPDirectiveKindEx(P.getPreprocessor().getSpelling(Tok));
if (DKind == OMPD_unknown)
return OMPD_unknown;
Commit for http://reviews.llvm.org/D10765 for OpenMP 4 target data directive parsing and sema. This commit is on behalf of Kelvin Li. llvm-svn: 242785
2015-07-21 21:44:28 +08:00
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-24 03:53:05 +08:00
for (unsigned I = 0; I < llvm::array_lengthof(F); ++I) {
if (DKind != F[I][0])
[OPENMP] NFC rewrite ParseOpenMPDirectiveKind New implementation is easier to read and extend. Differential Revision: http://reviews.llvm.org/D17197 llvm-svn: 260811
2016-02-13 14:53:38 +08:00
continue;
Commit for http://reviews.llvm.org/D10765 for OpenMP 4 target data directive parsing and sema. This commit is on behalf of Kelvin Li. llvm-svn: 242785
2015-07-21 21:44:28 +08:00
[OPENMP] NFC rewrite ParseOpenMPDirectiveKind New implementation is easier to read and extend. Differential Revision: http://reviews.llvm.org/D17197 llvm-svn: 260811
2016-02-13 14:53:38 +08:00
Tok = P.getPreprocessor().LookAhead(0);
[OpenMP][NFCI] Introduce llvm/IR/OpenMPConstants.h Summary: The new OpenMPConstants.h is a location for all OpenMP related constants (and helpers) to live. This patch moves the directives there (the enum OpenMPDirectiveKind) and rewires Clang to use the new location. Initially part of D69785. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: jholewinski, ppenzin, penzn, llvm-commits, cfe-commits, jfb, guansong, bollu, hiraditya, mgorny Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D69853
2019-11-05 12:00:49 +08:00
OpenMPDirectiveKindExWrapper SDKind =
[OPENMP] NFC rewrite ParseOpenMPDirectiveKind New implementation is easier to read and extend. Differential Revision: http://reviews.llvm.org/D17197 llvm-svn: 260811
2016-02-13 14:53:38 +08:00
Tok.isAnnotation()
? static_cast<unsigned>(OMPD_unknown)
: getOpenMPDirectiveKindEx(P.getPreprocessor().getSpelling(Tok));
if (SDKind == OMPD_unknown)
continue;
Commit for http://reviews.llvm.org/D10765 for OpenMP 4 target data directive parsing and sema. This commit is on behalf of Kelvin Li. llvm-svn: 242785
2015-07-21 21:44:28 +08:00
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-24 03:53:05 +08:00
if (SDKind == F[I][1]) {
[OPENMP] NFC rewrite ParseOpenMPDirectiveKind New implementation is easier to read and extend. Differential Revision: http://reviews.llvm.org/D17197 llvm-svn: 260811
2016-02-13 14:53:38 +08:00
P.ConsumeToken();
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-24 03:53:05 +08:00
DKind = F[I][2];
[OPENMP] Added initial support for 'omp parallel for'. llvm-svn: 212453
2014-07-07 21:01:15 +08:00
}
}
[openmp] Use Directive_enumSize instead of OMPD_unknown position Summary: Previously OMPD_unknown was last item in the Directive enumeration and its position was used in various comparison and assertion. With the new Directive enumeration, this should be change with llvm::omp::Directive_enumSize. This patch fix two place where it was not done in D81736. Reviewers: vdmitrie, jdoerfert, jdenny Reviewed By: jdoerfert Subscribers: yaxunl, guansong, sstefan1, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D82518
2020-06-25 21:17:15 +08:00
return unsigned(DKind) < llvm::omp::Directive_enumSize
? static_cast<OpenMPDirectiveKind>(DKind)
: OMPD_unknown;
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
}
static DeclarationName parseOpenMPReductionId(Parser &P) {
[OPENMP 4.0] Use 'declare reduction' constructs in 'reduction' clauses. OpenMP 4.0 allows to define custom reduction operations using '#pragma omp declare reduction' construct. Patch allows to use this custom defined reduction operations in 'reduction' clauses. llvm-svn: 263701
2016-03-17 18:19:46 +08:00
Token Tok = P.getCurToken();
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
Sema &Actions = P.getActions();
OverloadedOperatorKind OOK = OO_None;
[OPENMP 4.0] Use 'declare reduction' constructs in 'reduction' clauses. OpenMP 4.0 allows to define custom reduction operations using '#pragma omp declare reduction' construct. Patch allows to use this custom defined reduction operations in 'reduction' clauses. llvm-svn: 263701
2016-03-17 18:19:46 +08:00
// Allow to use 'operator' keyword for C++ operators
bool WithOperator = false;
if (Tok.is(tok::kw_operator)) {
P.ConsumeToken();
Tok = P.getCurToken();
WithOperator = true;
}
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
switch (Tok.getKind()) {
case tok::plus: // '+'
OOK = OO_Plus;
break;
case tok::minus: // '-'
OOK = OO_Minus;
break;
case tok::star: // '*'
OOK = OO_Star;
break;
case tok::amp: // '&'
OOK = OO_Amp;
break;
case tok::pipe: // '|'
OOK = OO_Pipe;
break;
case tok::caret: // '^'
OOK = OO_Caret;
break;
case tok::ampamp: // '&&'
OOK = OO_AmpAmp;
break;
case tok::pipepipe: // '||'
OOK = OO_PipePipe;
break;
case tok::identifier: // identifier
[OPENMP 4.0] Use 'declare reduction' constructs in 'reduction' clauses. OpenMP 4.0 allows to define custom reduction operations using '#pragma omp declare reduction' construct. Patch allows to use this custom defined reduction operations in 'reduction' clauses. llvm-svn: 263701
2016-03-17 18:19:46 +08:00
if (!WithOperator)
break;
Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC. llvm-svn: 304478
2017-06-02 05:26:38 +08:00
LLVM_FALLTHROUGH;
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
default:
P.Diag(Tok.getLocation(), diag::err_omp_expected_reduction_identifier);
P.SkipUntil(tok::colon, tok::r_paren, tok::annot_pragma_openmp_end,
Parser::StopBeforeMatch);
return DeclarationName();
}
P.ConsumeToken();
auto &DeclNames = Actions.getASTContext().DeclarationNames;
return OOK == OO_None ? DeclNames.getIdentifier(Tok.getIdentifierInfo())
: DeclNames.getCXXOperatorName(OOK);
}
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Parse 'omp declare reduction' construct.
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
///
/// declare-reduction-directive:
/// annot_pragma_openmp 'declare' 'reduction'
/// '(' <reduction_id> ':' <type> {',' <type>} ':' <expression> ')'
/// ['initializer' '(' ('omp_priv' '=' <expression>)|<function_call> ')']
/// annot_pragma_openmp_end
/// <reduction_id> is either a base language identifier or one of the following
/// operators: '+', '-', '*', '&', '|', '^', '&&' and '||'.
///
Parser::DeclGroupPtrTy
Parser::ParseOpenMPDeclareReductionDirective(AccessSpecifier AS) {
// Parse '('.
BalancedDelimiterTracker T(*this, tok::l_paren, tok::annot_pragma_openmp_end);
[OpenMP][NFCI] Introduce llvm/IR/OpenMPConstants.h Summary: The new OpenMPConstants.h is a location for all OpenMP related constants (and helpers) to live. This patch moves the directives there (the enum OpenMPDirectiveKind) and rewires Clang to use the new location. Initially part of D69785. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: jholewinski, ppenzin, penzn, llvm-commits, cfe-commits, jfb, guansong, bollu, hiraditya, mgorny Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D69853
2019-11-05 12:00:49 +08:00
if (T.expectAndConsume(
diag::err_expected_lparen_after,
getOpenMPDirectiveName(OMPD_declare_reduction).data())) {
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
SkipUntil(tok::annot_pragma_openmp_end, StopBeforeMatch);
return DeclGroupPtrTy();
}
DeclarationName Name = parseOpenMPReductionId(*this);
if (Name.isEmpty() && Tok.is(tok::annot_pragma_openmp_end))
return DeclGroupPtrTy();
// Consume ':'.
bool IsCorrect = !ExpectAndConsume(tok::colon);
if (!IsCorrect && Tok.is(tok::annot_pragma_openmp_end))
return DeclGroupPtrTy();
[OPENMP 4.0] Use 'declare reduction' constructs in 'reduction' clauses. OpenMP 4.0 allows to define custom reduction operations using '#pragma omp declare reduction' construct. Patch allows to use this custom defined reduction operations in 'reduction' clauses. llvm-svn: 263701
2016-03-17 18:19:46 +08:00
IsCorrect = IsCorrect && !Name.isEmpty();
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
if (Tok.is(tok::colon) || Tok.is(tok::annot_pragma_openmp_end)) {
Diag(Tok.getLocation(), diag::err_expected_type);
IsCorrect = false;
}
if (!IsCorrect && Tok.is(tok::annot_pragma_openmp_end))
return DeclGroupPtrTy();
SmallVector<std::pair<QualType, SourceLocation>, 8> ReductionTypes;
// Parse list of types until ':' token.
do {
ColonProtectionRAIIObject ColonRAII(*this);
SourceRange Range;
[NFC, Refactor] Rename the (scoped) enum DeclaratorContext's enumerators to remove duplication Since these are scoped enumerators, they have to be prefixed by DeclaratorContext, so lets remove Context from the name, and return some characters to the multiverse. Patch was reviewed here: https://reviews.llvm.org/D91011 Thank you to aaron, bruno, wyatt and barry for indulging me.
2020-11-11 13:40:12 +08:00
TypeResult TR = ParseTypeName(&Range, DeclaratorContext::Prototype, AS);
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
if (TR.isUsable()) {
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-24 03:53:05 +08:00
QualType ReductionType =
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
Actions.ActOnOpenMPDeclareReductionType(Range.getBegin(), TR);
if (!ReductionType.isNull()) {
ReductionTypes.push_back(
std::make_pair(ReductionType, Range.getBegin()));
}
} else {
SkipUntil(tok::comma, tok::colon, tok::annot_pragma_openmp_end,
StopBeforeMatch);
}
if (Tok.is(tok::colon) || Tok.is(tok::annot_pragma_openmp_end))
break;
// Consume ','.
if (ExpectAndConsume(tok::comma)) {
IsCorrect = false;
if (Tok.is(tok::annot_pragma_openmp_end)) {
Diag(Tok.getLocation(), diag::err_expected_type);
return DeclGroupPtrTy();
}
}
} while (Tok.isNot(tok::annot_pragma_openmp_end));
if (ReductionTypes.empty()) {
SkipUntil(tok::annot_pragma_openmp_end, StopBeforeMatch);
return DeclGroupPtrTy();
}
if (!IsCorrect && Tok.is(tok::annot_pragma_openmp_end))
return DeclGroupPtrTy();
// Consume ':'.
if (ExpectAndConsume(tok::colon))
IsCorrect = false;
if (Tok.is(tok::annot_pragma_openmp_end)) {
Diag(Tok.getLocation(), diag::err_expected_expression);
return DeclGroupPtrTy();
}
DeclGroupPtrTy DRD = Actions.ActOnOpenMPDeclareReductionDirectiveStart(
getCurScope(), Actions.getCurLexicalContext(), Name, ReductionTypes, AS);
// Parse <combiner> expression and then parse initializer if any for each
// correct type.
unsigned I = 0, E = ReductionTypes.size();
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-24 03:53:05 +08:00
for (Decl *D : DRD.get()) {
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
TentativeParsingAction TPA(*this);
ParseScope OMPDRScope(this, Scope::FnScope | Scope::DeclScope |
Place implictly declared functions at block scope Such implicitly declared functions behave as if the enclosing block contained the declaration extern int name() (C90, 6.3.3.2 Function calls), thus their names should have block scope (C90, 6.1.2.1 Scope of identifiers). This patch fixes https://bugs.llvm.org/show_bug.cgi?id=33224 Differential Revision: https://reviews.llvm.org/D33676 llvm-svn: 310616
2017-08-10 23:43:06 +08:00
Scope::CompoundStmtScope |
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
Scope::OpenMPDirectiveScope);
// Parse <combiner> expression.
Actions.ActOnOpenMPDeclareReductionCombinerStart(getCurScope(), D);
[OPENMP]Allow comma in combiner expression. Use ParseExpression() instead of ParseAssignmentExpression() to allow commas in combiner expressions.
2020-01-08 22:39:44 +08:00
ExprResult CombinerResult = Actions.ActOnFinishFullExpr(
ParseExpression().get(), D->getLocation(), /*DiscardedValue*/ false);
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
Actions.ActOnOpenMPDeclareReductionCombinerEnd(D, CombinerResult.get());
if (CombinerResult.isInvalid() && Tok.isNot(tok::r_paren) &&
Tok.isNot(tok::annot_pragma_openmp_end)) {
TPA.Commit();
IsCorrect = false;
break;
}
IsCorrect = !T.consumeClose() && IsCorrect && CombinerResult.isUsable();
ExprResult InitializerResult;
if (Tok.isNot(tok::annot_pragma_openmp_end)) {
// Parse <initializer> expression.
if (Tok.is(tok::identifier) &&
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-24 03:53:05 +08:00
Tok.getIdentifierInfo()->isStr("initializer")) {
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
ConsumeToken();
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-24 03:53:05 +08:00
} else {
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
Diag(Tok.getLocation(), diag::err_expected) << "'initializer'";
TPA.Commit();
IsCorrect = false;
break;
}
// Parse '('.
BalancedDelimiterTracker T(*this, tok::l_paren,
tok::annot_pragma_openmp_end);
IsCorrect =
!T.expectAndConsume(diag::err_expected_lparen_after, "initializer") &&
IsCorrect;
if (Tok.isNot(tok::annot_pragma_openmp_end)) {
ParseScope OMPDRScope(this, Scope::FnScope | Scope::DeclScope |
Place implictly declared functions at block scope Such implicitly declared functions behave as if the enclosing block contained the declaration extern int name() (C90, 6.3.3.2 Function calls), thus their names should have block scope (C90, 6.1.2.1 Scope of identifiers). This patch fixes https://bugs.llvm.org/show_bug.cgi?id=33224 Differential Revision: https://reviews.llvm.org/D33676 llvm-svn: 310616
2017-08-10 23:43:06 +08:00
Scope::CompoundStmtScope |
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
Scope::OpenMPDirectiveScope);
// Parse expression.
[OPENMP] Fix for PR34445: Reduction initializer segfaults at runtime in move constructor. Previously user-defined reduction initializer was considered as an assignment expression, not as initializer. Fixed this by treating the initializer expression as an initializer. llvm-svn: 312638
2017-09-06 22:49:58 +08:00
VarDecl *OmpPrivParm =
Actions.ActOnOpenMPDeclareReductionInitializerStart(getCurScope(),
D);
// Check if initializer is omp_priv <init_expr> or something else.
if (Tok.is(tok::identifier) &&
Tok.getIdentifierInfo()->isStr("omp_priv")) {
[OPENMP]Use copy constructors instead of assignment operators in declare reduction initializers. Better to use copy constructor at the initialization of the declare reduction construct rather than assignment operator.
2019-11-13 00:19:26 +08:00
ConsumeToken();
ParseOpenMPReductionInitializerForDecl(OmpPrivParm);
[OPENMP] Fix for PR34445: Reduction initializer segfaults at runtime in move constructor. Previously user-defined reduction initializer was considered as an assignment expression, not as initializer. Fixed this by treating the initializer expression as an initializer. llvm-svn: 312638
2017-09-06 22:49:58 +08:00
} else {
InitializerResult = Actions.ActOnFinishFullExpr(
ParseAssignmentExpression().get(), D->getLocation(),
Refactor the way we handle diagnosing unused expression results. Rather than sprinkle calls to DiagnoseUnusedExprResult() around in places where we want diagnostics, we now diagnose unused expression statements and full expressions in a more generic way when acting on the final expression statement. This results in more appropriate diagnostics for [[nodiscard]] where we were previously lacking them, such as when the body of a for loop is not a compound statement. This patch fixes PR39837. llvm-svn: 350404
2019-01-05 00:58:14 +08:00
/*DiscardedValue*/ false);
[OPENMP] Fix for PR34445: Reduction initializer segfaults at runtime in move constructor. Previously user-defined reduction initializer was considered as an assignment expression, not as initializer. Fixed this by treating the initializer expression as an initializer. llvm-svn: 312638
2017-09-06 22:49:58 +08:00
}
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
Actions.ActOnOpenMPDeclareReductionInitializerEnd(
[OPENMP] Fix for PR34445: Reduction initializer segfaults at runtime in move constructor. Previously user-defined reduction initializer was considered as an assignment expression, not as initializer. Fixed this by treating the initializer expression as an initializer. llvm-svn: 312638
2017-09-06 22:49:58 +08:00
D, InitializerResult.get(), OmpPrivParm);
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
if (InitializerResult.isInvalid() && Tok.isNot(tok::r_paren) &&
Tok.isNot(tok::annot_pragma_openmp_end)) {
TPA.Commit();
IsCorrect = false;
break;
}
IsCorrect =
!T.consumeClose() && IsCorrect && !InitializerResult.isInvalid();
}
}
++I;
// Revert parsing if not the last type, otherwise accept it, we're done with
// parsing.
if (I != E)
TPA.Revert();
else
TPA.Commit();
}
return Actions.ActOnOpenMPDeclareReductionDirectiveEnd(getCurScope(), DRD,
IsCorrect);
[OPENMP] Added initial support for 'omp parallel for'. llvm-svn: 212453
2014-07-07 21:01:15 +08:00
}
[OPENMP] Fix for PR34445: Reduction initializer segfaults at runtime in move constructor. Previously user-defined reduction initializer was considered as an assignment expression, not as initializer. Fixed this by treating the initializer expression as an initializer. llvm-svn: 312638
2017-09-06 22:49:58 +08:00
void Parser::ParseOpenMPReductionInitializerForDecl(VarDecl *OmpPrivParm) {
// Parse declarator '=' initializer.
// If a '==' or '+=' is found, suggest a fixit to '='.
if (isTokenEqualOrEqualTypo()) {
ConsumeToken();
if (Tok.is(tok::code_completion)) {
[CodeCompletion] Avoid spurious signature help for init-list args Somewhat surprisingly, signature help is emitted as a side-effect of computing the expected type of a function argument. The reason is that both actions require enumerating the possible function signatures and running partial overload resolution, and doing this twice would be wasteful and complicated. Change #1: document this, it's subtle :-) However, sometimes we need to compute the expected type without having reached the code completion cursor yet - in particular to allow completion of designators. eb4ab3358cd4dc834a761191b5531b38114f7b13 did this but introduced a regression - it emits signature help in the wrong location as a side-effect. Change #2: only emit signature help if the code completion cursor was reached. Currently there is PP.isCodeCompletionReached(), but we can't use it because it's set *after* running code completion. It'd be nice to set this implicitly when the completion token is lexed, but ConsumeCodeCompletionToken() makes this complicated. Change #3: call cutOffParsing() *first* when seeing a completion token. After this, the fact that the Sema::Produce*SignatureHelp() functions are even more confusing, as they only sometimes do that. I don't want to rename them in this patch as it's another large mechanical change, but we should soon. Change #4: prepare to rename ProduceSignatureHelp() to GuessArgumentType() etc. Differential Revision: https://reviews.llvm.org/D98488
2021-03-12 19:00:54 +08:00
cutOffParsing();
[OPENMP] Fix for PR34445: Reduction initializer segfaults at runtime in move constructor. Previously user-defined reduction initializer was considered as an assignment expression, not as initializer. Fixed this by treating the initializer expression as an initializer. llvm-svn: 312638
2017-09-06 22:49:58 +08:00
Actions.CodeCompleteInitializer(getCurScope(), OmpPrivParm);
Actions.FinalizeDeclaration(OmpPrivParm);
return;
}
[OPENMP]Use copy constructors instead of assignment operators in declare reduction initializers. Better to use copy constructor at the initialization of the declare reduction construct rather than assignment operator.
2019-11-13 00:19:26 +08:00
PreferredType.enterVariableInit(Tok.getLocation(), OmpPrivParm);
[OPENMP] Restore allowing of braced initializers in the declare reduction init. Braced initializers were not accepted after the last fix in the initialier.Restored previous functionality.
2020-01-03 04:49:08 +08:00
ExprResult Init = ParseInitializer();
[OPENMP] Fix for PR34445: Reduction initializer segfaults at runtime in move constructor. Previously user-defined reduction initializer was considered as an assignment expression, not as initializer. Fixed this by treating the initializer expression as an initializer. llvm-svn: 312638
2017-09-06 22:49:58 +08:00
if (Init.isInvalid()) {
SkipUntil(tok::r_paren, tok::annot_pragma_openmp_end, StopBeforeMatch);
Actions.ActOnInitializerError(OmpPrivParm);
} else {
Actions.AddInitializerToDecl(OmpPrivParm, Init.get(),
/*DirectInit=*/false);
}
} else if (Tok.is(tok::l_paren)) {
// Parse C++ direct initializer: '(' expression-list ')'
BalancedDelimiterTracker T(*this, tok::l_paren);
T.consumeOpen();
ExprVector Exprs;
CommaLocsTy CommaLocs;
[CodeComplete] Report location of opening parens for signature help Summary: Used in clangd. Reviewers: sammccall Reviewed By: sammccall Subscribers: ioeric, kadircet, cfe-commits Differential Revision: https://reviews.llvm.org/D51436 llvm-svn: 341063
2018-08-30 21:08:03 +08:00
SourceLocation LParLoc = T.getOpenLocation();
[CodeComplete] Propagate preferred type for function arguments in more cases Summary: See the added test for some new cases. This change also removes special code completion calls inside the ParseExpressionList function now that we properly propagate expected type to the function responsible for parsing elements of the expression list (ParseAssignmentExpression). Reviewers: kadircet Reviewed By: kadircet Subscribers: xbolva00, jdoerfert, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58541 llvm-svn: 354864
2019-02-26 19:01:50 +08:00
auto RunSignatureHelp = [this, OmpPrivParm, LParLoc, &Exprs]() {
QualType PreferredType = Actions.ProduceConstructorSignatureHelp(
getCurScope(), OmpPrivParm->getType()->getCanonicalTypeInternal(),
OmpPrivParm->getLocation(), Exprs, LParLoc);
CalledSignatureHelp = true;
return PreferredType;
};
if (ParseExpressionList(Exprs, CommaLocs, [&] {
PreferredType.enterFunctionArgument(Tok.getLocation(),
RunSignatureHelp);
})) {
if (PP.isCodeCompletionReached() && !CalledSignatureHelp)
RunSignatureHelp();
[OPENMP] Fix for PR34445: Reduction initializer segfaults at runtime in move constructor. Previously user-defined reduction initializer was considered as an assignment expression, not as initializer. Fixed this by treating the initializer expression as an initializer. llvm-svn: 312638
2017-09-06 22:49:58 +08:00
Actions.ActOnInitializerError(OmpPrivParm);
SkipUntil(tok::r_paren, tok::annot_pragma_openmp_end, StopBeforeMatch);
} else {
// Match the ')'.
[OPENMP] Make clauses closing loc point to right bracket. For some of the clauses the closing location erroneously points to the beginning of the next clause rather than on the location of the closing bracket of the clause. llvm-svn: 336460
2018-07-07 03:35:42 +08:00
SourceLocation RLoc = Tok.getLocation();
if (!T.consumeClose())
RLoc = T.getCloseLocation();
[OPENMP] Fix for PR34445: Reduction initializer segfaults at runtime in move constructor. Previously user-defined reduction initializer was considered as an assignment expression, not as initializer. Fixed this by treating the initializer expression as an initializer. llvm-svn: 312638
2017-09-06 22:49:58 +08:00
assert(!Exprs.empty() && Exprs.size() - 1 == CommaLocs.size() &&
"Unexpected number of commas!");
[OPENMP] Make clauses closing loc point to right bracket. For some of the clauses the closing location erroneously points to the beginning of the next clause rather than on the location of the closing bracket of the clause. llvm-svn: 336460
2018-07-07 03:35:42 +08:00
ExprResult Initializer =
Actions.ActOnParenListExpr(T.getOpenLocation(), RLoc, Exprs);
[OPENMP] Fix for PR34445: Reduction initializer segfaults at runtime in move constructor. Previously user-defined reduction initializer was considered as an assignment expression, not as initializer. Fixed this by treating the initializer expression as an initializer. llvm-svn: 312638
2017-09-06 22:49:58 +08:00
Actions.AddInitializerToDecl(OmpPrivParm, Initializer.get(),
/*DirectInit=*/true);
}
} else if (getLangOpts().CPlusPlus11 && Tok.is(tok::l_brace)) {
// Parse C++0x braced-init-list.
Diag(Tok, diag::warn_cxx98_compat_generalized_initializer_lists);
ExprResult Init(ParseBraceInitializer());
if (Init.isInvalid()) {
Actions.ActOnInitializerError(OmpPrivParm);
} else {
Actions.AddInitializerToDecl(OmpPrivParm, Init.get(),
/*DirectInit=*/true);
}
} else {
Actions.ActOnUninitializedDecl(OmpPrivParm);
}
}
[OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive. This patch implements parsing and sema for "omp declare mapper" directive. User defined mapper, i.e., declare mapper directive, is a new feature in OpenMP 5.0. It is introduced to extend existing map clauses for the purpose of simplifying the copy of complex data structures between host and device (i.e., deep copy). An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(struct S s) map(s, s.d[0:s.len]) // Memory region that d points to is also mapped using this mapper. Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D56326 llvm-svn: 352906
2019-02-02 04:25:04 +08:00
/// Parses 'omp declare mapper' directive.
///
/// declare-mapper-directive:
/// annot_pragma_openmp 'declare' 'mapper' '(' [<mapper-identifier> ':']
/// <type> <var> ')' [<clause>[[,] <clause>] ... ]
/// annot_pragma_openmp_end
/// <mapper-identifier> and <var> are base language identifiers.
///
Parser::DeclGroupPtrTy
Parser::ParseOpenMPDeclareMapperDirective(AccessSpecifier AS) {
bool IsCorrect = true;
// Parse '('
BalancedDelimiterTracker T(*this, tok::l_paren, tok::annot_pragma_openmp_end);
if (T.expectAndConsume(diag::err_expected_lparen_after,
[OpenMP][NFCI] Introduce llvm/IR/OpenMPConstants.h Summary: The new OpenMPConstants.h is a location for all OpenMP related constants (and helpers) to live. This patch moves the directives there (the enum OpenMPDirectiveKind) and rewires Clang to use the new location. Initially part of D69785. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: jholewinski, ppenzin, penzn, llvm-commits, cfe-commits, jfb, guansong, bollu, hiraditya, mgorny Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D69853
2019-11-05 12:00:49 +08:00
getOpenMPDirectiveName(OMPD_declare_mapper).data())) {
[OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive. This patch implements parsing and sema for "omp declare mapper" directive. User defined mapper, i.e., declare mapper directive, is a new feature in OpenMP 5.0. It is introduced to extend existing map clauses for the purpose of simplifying the copy of complex data structures between host and device (i.e., deep copy). An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(struct S s) map(s, s.d[0:s.len]) // Memory region that d points to is also mapped using this mapper. Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D56326 llvm-svn: 352906
2019-02-02 04:25:04 +08:00
SkipUntil(tok::annot_pragma_openmp_end, StopBeforeMatch);
return DeclGroupPtrTy();
}
// Parse <mapper-identifier>
auto &DeclNames = Actions.getASTContext().DeclarationNames;
DeclarationName MapperId;
if (PP.LookAhead(0).is(tok::colon)) {
if (Tok.isNot(tok::identifier) && Tok.isNot(tok::kw_default)) {
Diag(Tok.getLocation(), diag::err_omp_mapper_illegal_identifier);
IsCorrect = false;
} else {
MapperId = DeclNames.getIdentifier(Tok.getIdentifierInfo());
}
ConsumeToken();
// Consume ':'.
ExpectAndConsume(tok::colon);
} else {
// If no mapper identifier is provided, its name is "default" by default
MapperId =
DeclNames.getIdentifier(&Actions.getASTContext().Idents.get("default"));
}
if (!IsCorrect && Tok.is(tok::annot_pragma_openmp_end))
return DeclGroupPtrTy();
// Parse <type> <var>
DeclarationName VName;
QualType MapperType;
SourceRange Range;
TypeResult ParsedType = parseOpenMPDeclareMapperVarDecl(Range, VName, AS);
if (ParsedType.isUsable())
MapperType =
Actions.ActOnOpenMPDeclareMapperType(Range.getBegin(), ParsedType);
if (MapperType.isNull())
IsCorrect = false;
if (!IsCorrect) {
SkipUntil(tok::annot_pragma_openmp_end, Parser::StopBeforeMatch);
return DeclGroupPtrTy();
}
// Consume ')'.
IsCorrect &= !T.consumeClose();
if (!IsCorrect) {
SkipUntil(tok::annot_pragma_openmp_end, Parser::StopBeforeMatch);
return DeclGroupPtrTy();
}
// Enter scope.
DeclarationNameInfo DirName;
SourceLocation Loc = Tok.getLocation();
unsigned ScopeFlags = Scope::FnScope | Scope::DeclScope |
Scope::CompoundStmtScope | Scope::OpenMPDirectiveScope;
ParseScope OMPDirectiveScope(this, ScopeFlags);
Actions.StartOpenMPDSABlock(OMPD_declare_mapper, DirName, getCurScope(), Loc);
// Add the mapper variable declaration.
[OPENMP]Redesign of OMPExecutableDirective/OMPDeclarativeDirective representation. Summary: Introduced OMPChildren class to handle all associated clauses, statement and child expressions/statements. It allows to represent some directives more correctly (like flush, depobj etc. with pseudo clauses, ordered depend directives, which are standalone, and target data directives). Also, it will make easier to avoid using of CapturedStmt in directives, if required (atomic, tile etc. directives). Also, it simplifies serialization/deserialization of the executable/declarative directives. Reduces number of allocation operations for mapper declarations. Reviewers: jdoerfert Subscribers: yaxunl, guansong, jfb, cfe-commits, sstefan1, aaron.ballman, caomhin Tags: #clang Differential Revision: https://reviews.llvm.org/D83261
2020-06-27 05:42:31 +08:00
ExprResult MapperVarRef = Actions.ActOnOpenMPDeclareMapperDirectiveVarDecl(
getCurScope(), MapperType, Range.getBegin(), VName);
[OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive. This patch implements parsing and sema for "omp declare mapper" directive. User defined mapper, i.e., declare mapper directive, is a new feature in OpenMP 5.0. It is introduced to extend existing map clauses for the purpose of simplifying the copy of complex data structures between host and device (i.e., deep copy). An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(struct S s) map(s, s.d[0:s.len]) // Memory region that d points to is also mapped using this mapper. Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D56326 llvm-svn: 352906
2019-02-02 04:25:04 +08:00
// Parse map clauses.
SmallVector<OMPClause *, 6> Clauses;
while (Tok.isNot(tok::annot_pragma_openmp_end)) {
OpenMPClauseKind CKind = Tok.isAnnotation()
? OMPC_unknown
: getOpenMPClauseKind(PP.getSpelling(Tok));
Actions.StartOpenMPClause(CKind);
OMPClause *Clause =
[OPENMP]Redesign of OMPExecutableDirective/OMPDeclarativeDirective representation. Summary: Introduced OMPChildren class to handle all associated clauses, statement and child expressions/statements. It allows to represent some directives more correctly (like flush, depobj etc. with pseudo clauses, ordered depend directives, which are standalone, and target data directives). Also, it will make easier to avoid using of CapturedStmt in directives, if required (atomic, tile etc. directives). Also, it simplifies serialization/deserialization of the executable/declarative directives. Reduces number of allocation operations for mapper declarations. Reviewers: jdoerfert Subscribers: yaxunl, guansong, jfb, cfe-commits, sstefan1, aaron.ballman, caomhin Tags: #clang Differential Revision: https://reviews.llvm.org/D83261
2020-06-27 05:42:31 +08:00
ParseOpenMPClause(OMPD_declare_mapper, CKind, Clauses.empty());
[OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive. This patch implements parsing and sema for "omp declare mapper" directive. User defined mapper, i.e., declare mapper directive, is a new feature in OpenMP 5.0. It is introduced to extend existing map clauses for the purpose of simplifying the copy of complex data structures between host and device (i.e., deep copy). An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(struct S s) map(s, s.d[0:s.len]) // Memory region that d points to is also mapped using this mapper. Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D56326 llvm-svn: 352906
2019-02-02 04:25:04 +08:00
if (Clause)
Clauses.push_back(Clause);
else
IsCorrect = false;
// Skip ',' if any.
if (Tok.is(tok::comma))
ConsumeToken();
Actions.EndOpenMPClause();
}
if (Clauses.empty()) {
Diag(Tok, diag::err_omp_expected_clause)
<< getOpenMPDirectiveName(OMPD_declare_mapper);
IsCorrect = false;
}
// Exit scope.
Actions.EndOpenMPDSABlock(nullptr);
OMPDirectiveScope.Exit();
[OPENMP]Redesign of OMPExecutableDirective/OMPDeclarativeDirective representation. Summary: Introduced OMPChildren class to handle all associated clauses, statement and child expressions/statements. It allows to represent some directives more correctly (like flush, depobj etc. with pseudo clauses, ordered depend directives, which are standalone, and target data directives). Also, it will make easier to avoid using of CapturedStmt in directives, if required (atomic, tile etc. directives). Also, it simplifies serialization/deserialization of the executable/declarative directives. Reduces number of allocation operations for mapper declarations. Reviewers: jdoerfert Subscribers: yaxunl, guansong, jfb, cfe-commits, sstefan1, aaron.ballman, caomhin Tags: #clang Differential Revision: https://reviews.llvm.org/D83261
2020-06-27 05:42:31 +08:00
DeclGroupPtrTy DG = Actions.ActOnOpenMPDeclareMapperDirective(
getCurScope(), Actions.getCurLexicalContext(), MapperId, MapperType,
Range.getBegin(), VName, AS, MapperVarRef.get(), Clauses);
[OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive. This patch implements parsing and sema for "omp declare mapper" directive. User defined mapper, i.e., declare mapper directive, is a new feature in OpenMP 5.0. It is introduced to extend existing map clauses for the purpose of simplifying the copy of complex data structures between host and device (i.e., deep copy). An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(struct S s) map(s, s.d[0:s.len]) // Memory region that d points to is also mapped using this mapper. Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D56326 llvm-svn: 352906
2019-02-02 04:25:04 +08:00
if (!IsCorrect)
return DeclGroupPtrTy();
[OPENMP]Redesign of OMPExecutableDirective/OMPDeclarativeDirective representation. Summary: Introduced OMPChildren class to handle all associated clauses, statement and child expressions/statements. It allows to represent some directives more correctly (like flush, depobj etc. with pseudo clauses, ordered depend directives, which are standalone, and target data directives). Also, it will make easier to avoid using of CapturedStmt in directives, if required (atomic, tile etc. directives). Also, it simplifies serialization/deserialization of the executable/declarative directives. Reduces number of allocation operations for mapper declarations. Reviewers: jdoerfert Subscribers: yaxunl, guansong, jfb, cfe-commits, sstefan1, aaron.ballman, caomhin Tags: #clang Differential Revision: https://reviews.llvm.org/D83261
2020-06-27 05:42:31 +08:00
return DG;
[OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive. This patch implements parsing and sema for "omp declare mapper" directive. User defined mapper, i.e., declare mapper directive, is a new feature in OpenMP 5.0. It is introduced to extend existing map clauses for the purpose of simplifying the copy of complex data structures between host and device (i.e., deep copy). An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(struct S s) map(s, s.d[0:s.len]) // Memory region that d points to is also mapped using this mapper. Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D56326 llvm-svn: 352906
2019-02-02 04:25:04 +08:00
}
TypeResult Parser::parseOpenMPDeclareMapperVarDecl(SourceRange &Range,
DeclarationName &Name,
AccessSpecifier AS) {
// Parse the common declaration-specifiers piece.
Parser::DeclSpecContext DSC = Parser::DeclSpecContext::DSC_type_specifier;
DeclSpec DS(AttrFactory);
ParseSpecifierQualifierList(DS, AS, DSC);
// Parse the declarator.
[NFC, Refactor] Rename the (scoped) enum DeclaratorContext's enumerators to remove duplication Since these are scoped enumerators, they have to be prefixed by DeclaratorContext, so lets remove Context from the name, and return some characters to the multiverse. Patch was reviewed here: https://reviews.llvm.org/D91011 Thank you to aaron, bruno, wyatt and barry for indulging me.
2020-11-11 13:40:12 +08:00
DeclaratorContext Context = DeclaratorContext::Prototype;
[OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive. This patch implements parsing and sema for "omp declare mapper" directive. User defined mapper, i.e., declare mapper directive, is a new feature in OpenMP 5.0. It is introduced to extend existing map clauses for the purpose of simplifying the copy of complex data structures between host and device (i.e., deep copy). An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(struct S s) map(s, s.d[0:s.len]) // Memory region that d points to is also mapped using this mapper. Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D56326 llvm-svn: 352906
2019-02-02 04:25:04 +08:00
Declarator DeclaratorInfo(DS, Context);
ParseDeclarator(DeclaratorInfo);
Range = DeclaratorInfo.getSourceRange();
if (DeclaratorInfo.getIdentifier() == nullptr) {
Diag(Tok.getLocation(), diag::err_omp_mapper_expected_declarator);
return true;
}
Name = Actions.GetNameForDeclarator(DeclaratorInfo).getName();
return Actions.ActOnOpenMPDeclareMapperVarDecl(getCurScope(), DeclaratorInfo);
}
[OPENMP 4.0] Parsing/sema analysis for 'simdlen' clause in 'declare simd' construct. OpenMP 4.0 defines '#pragma omp declare simd' construct that may have associated 'simdlen' clause with constant positive expression as an argument: simdlen(<const_expr>) Patch adds parsin and semantic analysis for simdlen clause. llvm-svn: 265668
2016-04-07 20:45:37 +08:00
namespace {
/// RAII that recreates function context for correct parsing of clauses of
/// 'declare simd' construct.
/// OpenMP, 2.8.2 declare simd Construct
/// The expressions appearing in the clauses of this directive are evaluated in
/// the scope of the arguments of the function declaration or definition.
class FNContextRAII final {
Parser &P;
Sema::CXXThisScopeRAII *ThisScope;
DR458: Search template parameter scopes in the right order. C++ unqualified name lookup searches template parameter scopes immediately after finishing searching the entity the parameters belong to. (Eg, for a class template, you search the template parameter scope after looking in that class template and its base classes and before looking in the scope containing the class template.) This is complicated by the fact that scope lookup within a template parameter scope looks in a different sequence of places prior to reaching the end of the declarator-id in the template declaration. We used to approximate the proper lookup rule with a hack in the scope / decl context walk inside name lookup. Now we instead compute the lookup parent for each template parameter scope. In order to get this right, we now make sure to enter a distinct Scope for each template parameter scope, and make sure to re-enter the enclosing class scopes properly when handling delay-parsed regions within a class.
2020-06-17 07:55:56 +08:00
Parser::MultiParseScope Scopes;
[OPENMP 4.0] Parsing/sema analysis for 'simdlen' clause in 'declare simd' construct. OpenMP 4.0 defines '#pragma omp declare simd' construct that may have associated 'simdlen' clause with constant positive expression as an argument: simdlen(<const_expr>) Patch adds parsin and semantic analysis for simdlen clause. llvm-svn: 265668
2016-04-07 20:45:37 +08:00
bool HasFunScope = false;
FNContextRAII() = delete;
FNContextRAII(const FNContextRAII &) = delete;
FNContextRAII &operator=(const FNContextRAII &) = delete;
public:
DR458: Search template parameter scopes in the right order. C++ unqualified name lookup searches template parameter scopes immediately after finishing searching the entity the parameters belong to. (Eg, for a class template, you search the template parameter scope after looking in that class template and its base classes and before looking in the scope containing the class template.) This is complicated by the fact that scope lookup within a template parameter scope looks in a different sequence of places prior to reaching the end of the declarator-id in the template declaration. We used to approximate the proper lookup rule with a hack in the scope / decl context walk inside name lookup. Now we instead compute the lookup parent for each template parameter scope. In order to get this right, we now make sure to enter a distinct Scope for each template parameter scope, and make sure to re-enter the enclosing class scopes properly when handling delay-parsed regions within a class.
2020-06-17 07:55:56 +08:00
FNContextRAII(Parser &P, Parser::DeclGroupPtrTy Ptr) : P(P), Scopes(P) {
[OPENMP 4.0] Parsing/sema analysis for 'simdlen' clause in 'declare simd' construct. OpenMP 4.0 defines '#pragma omp declare simd' construct that may have associated 'simdlen' clause with constant positive expression as an argument: simdlen(<const_expr>) Patch adds parsin and semantic analysis for simdlen clause. llvm-svn: 265668
2016-04-07 20:45:37 +08:00
Decl *D = *Ptr.get().begin();
NamedDecl *ND = dyn_cast<NamedDecl>(D);
RecordDecl *RD = dyn_cast_or_null<RecordDecl>(D->getDeclContext());
Sema &Actions = P.getActions();
// Allow 'this' within late-parsed attributes.
[OpenCL] Add generic AS to 'this' pointer Address spaces are cast into generic before invoking the constructor. Added support for a trailing Qualifiers object in FunctionProtoType. Note: This recommits the previously reverted patch, but now it is commited together with a fix for lldb. Differential Revision: https://reviews.llvm.org/D54862 llvm-svn: 349019
2018-12-13 18:15:27 +08:00
ThisScope = new Sema::CXXThisScopeRAII(Actions, RD, Qualifiers(),
[OPENMP 4.0] Parsing/sema analysis for 'simdlen' clause in 'declare simd' construct. OpenMP 4.0 defines '#pragma omp declare simd' construct that may have associated 'simdlen' clause with constant positive expression as an argument: simdlen(<const_expr>) Patch adds parsin and semantic analysis for simdlen clause. llvm-svn: 265668
2016-04-07 20:45:37 +08:00
ND && ND->isCXXInstanceMember());
// If the Decl is templatized, add template parameters to scope.
DR458: Search template parameter scopes in the right order. C++ unqualified name lookup searches template parameter scopes immediately after finishing searching the entity the parameters belong to. (Eg, for a class template, you search the template parameter scope after looking in that class template and its base classes and before looking in the scope containing the class template.) This is complicated by the fact that scope lookup within a template parameter scope looks in a different sequence of places prior to reaching the end of the declarator-id in the template declaration. We used to approximate the proper lookup rule with a hack in the scope / decl context walk inside name lookup. Now we instead compute the lookup parent for each template parameter scope. In order to get this right, we now make sure to enter a distinct Scope for each template parameter scope, and make sure to re-enter the enclosing class scopes properly when handling delay-parsed regions within a class.
2020-06-17 07:55:56 +08:00
// FIXME: Track CurTemplateDepth?
P.ReenterTemplateScopes(Scopes, D);
[OPENMP 4.0] Parsing/sema analysis for 'simdlen' clause in 'declare simd' construct. OpenMP 4.0 defines '#pragma omp declare simd' construct that may have associated 'simdlen' clause with constant positive expression as an argument: simdlen(<const_expr>) Patch adds parsin and semantic analysis for simdlen clause. llvm-svn: 265668
2016-04-07 20:45:37 +08:00
// If the Decl is on a function, add function parameters to the scope.
DR458: Search template parameter scopes in the right order. C++ unqualified name lookup searches template parameter scopes immediately after finishing searching the entity the parameters belong to. (Eg, for a class template, you search the template parameter scope after looking in that class template and its base classes and before looking in the scope containing the class template.) This is complicated by the fact that scope lookup within a template parameter scope looks in a different sequence of places prior to reaching the end of the declarator-id in the template declaration. We used to approximate the proper lookup rule with a hack in the scope / decl context walk inside name lookup. Now we instead compute the lookup parent for each template parameter scope. In order to get this right, we now make sure to enter a distinct Scope for each template parameter scope, and make sure to re-enter the enclosing class scopes properly when handling delay-parsed regions within a class.
2020-06-17 07:55:56 +08:00
if (D->isFunctionOrFunctionTemplate()) {
HasFunScope = true;
Scopes.Enter(Scope::FnScope | Scope::DeclScope |
Scope::CompoundStmtScope);
[OPENMP 4.0] Parsing/sema analysis for 'simdlen' clause in 'declare simd' construct. OpenMP 4.0 defines '#pragma omp declare simd' construct that may have associated 'simdlen' clause with constant positive expression as an argument: simdlen(<const_expr>) Patch adds parsin and semantic analysis for simdlen clause. llvm-svn: 265668
2016-04-07 20:45:37 +08:00
Actions.ActOnReenterFunctionContext(Actions.getCurScope(), D);
DR458: Search template parameter scopes in the right order. C++ unqualified name lookup searches template parameter scopes immediately after finishing searching the entity the parameters belong to. (Eg, for a class template, you search the template parameter scope after looking in that class template and its base classes and before looking in the scope containing the class template.) This is complicated by the fact that scope lookup within a template parameter scope looks in a different sequence of places prior to reaching the end of the declarator-id in the template declaration. We used to approximate the proper lookup rule with a hack in the scope / decl context walk inside name lookup. Now we instead compute the lookup parent for each template parameter scope. In order to get this right, we now make sure to enter a distinct Scope for each template parameter scope, and make sure to re-enter the enclosing class scopes properly when handling delay-parsed regions within a class.
2020-06-17 07:55:56 +08:00
}
[OPENMP 4.0] Parsing/sema analysis for 'simdlen' clause in 'declare simd' construct. OpenMP 4.0 defines '#pragma omp declare simd' construct that may have associated 'simdlen' clause with constant positive expression as an argument: simdlen(<const_expr>) Patch adds parsin and semantic analysis for simdlen clause. llvm-svn: 265668
2016-04-07 20:45:37 +08:00
}
~FNContextRAII() {
DR458: Search template parameter scopes in the right order. C++ unqualified name lookup searches template parameter scopes immediately after finishing searching the entity the parameters belong to. (Eg, for a class template, you search the template parameter scope after looking in that class template and its base classes and before looking in the scope containing the class template.) This is complicated by the fact that scope lookup within a template parameter scope looks in a different sequence of places prior to reaching the end of the declarator-id in the template declaration. We used to approximate the proper lookup rule with a hack in the scope / decl context walk inside name lookup. Now we instead compute the lookup parent for each template parameter scope. In order to get this right, we now make sure to enter a distinct Scope for each template parameter scope, and make sure to re-enter the enclosing class scopes properly when handling delay-parsed regions within a class.
2020-06-17 07:55:56 +08:00
if (HasFunScope)
[OPENMP 4.0] Parsing/sema analysis for 'simdlen' clause in 'declare simd' construct. OpenMP 4.0 defines '#pragma omp declare simd' construct that may have associated 'simdlen' clause with constant positive expression as an argument: simdlen(<const_expr>) Patch adds parsin and semantic analysis for simdlen clause. llvm-svn: 265668
2016-04-07 20:45:37 +08:00
P.getActions().ActOnExitFunctionContext();
delete ThisScope;
}
};
} // namespace
[OPENMP 4.0] Support for 'aligned' clause in 'declare simd' directive. The aligned clause declares that the object to which each list item points is aligned to the number of bytes expressed in the optional parameter of the aligned clause. 'aligned' '(' <argument-list> [ ':' <alignment> ] ')' The optional parameter of the aligned clause, alignment, must be a constant positive integer expression. If no optional parameter is specified, implementation-defined default alignments for SIMD instructions on the target platforms are assumed. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266052
2016-04-12 17:35:56 +08:00
/// Parses clauses for 'declare simd' directive.
/// clause:
/// 'inbranch' | 'notinbranch'
/// 'simdlen' '(' <expr> ')'
/// { 'uniform' '(' <argument_list> ')' }
/// { 'aligned '(' <argument_list> [ ':' <alignment> ] ')' }
[OPENMP 4.0] Support for 'linear' clause in 'declare simd' directive. The linear clause declares one or more list items to be private to a SIMD lane and to have a linear relationship with respect to the iteration space of a loop. 'linear' '(' <linear-list> [ ':' <linear-step> ] ')' When a linear-step expression is specified in a linear clause it must be either a constant integer expression or an integer-typed parameter that is specified in a uniform clause on the directive. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266056
2016-04-12 19:02:11 +08:00
/// { 'linear '(' <argument_list> [ ':' <step> ] ')' }
static bool parseDeclareSimdClauses(
Parser &P, OMPDeclareSimdDeclAttr::BranchStateTy &BS, ExprResult &SimdLen,
SmallVectorImpl<Expr *> &Uniforms, SmallVectorImpl<Expr *> &Aligneds,
SmallVectorImpl<Expr *> &Alignments, SmallVectorImpl<Expr *> &Linears,
SmallVectorImpl<unsigned> &LinModifiers, SmallVectorImpl<Expr *> &Steps) {
[OPENMP 4.0] Support for 'aligned' clause in 'declare simd' directive. The aligned clause declares that the object to which each list item points is aligned to the number of bytes expressed in the optional parameter of the aligned clause. 'aligned' '(' <argument-list> [ ':' <alignment> ] ')' The optional parameter of the aligned clause, alignment, must be a constant positive integer expression. If no optional parameter is specified, implementation-defined default alignments for SIMD instructions on the target platforms are assumed. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266052
2016-04-12 17:35:56 +08:00
SourceRange BSRange;
const Token &Tok = P.getCurToken();
bool IsError = false;
while (Tok.isNot(tok::annot_pragma_openmp_end)) {
if (Tok.isNot(tok::identifier))
break;
OMPDeclareSimdDeclAttr::BranchStateTy Out;
IdentifierInfo *II = Tok.getIdentifierInfo();
StringRef ClauseName = II->getName();
// Parse 'inranch|notinbranch' clauses.
if (OMPDeclareSimdDeclAttr::ConvertStrToBranchStateTy(ClauseName, Out)) {
if (BS != OMPDeclareSimdDeclAttr::BS_Undefined && BS != Out) {
P.Diag(Tok, diag::err_omp_declare_simd_inbranch_notinbranch)
<< ClauseName
<< OMPDeclareSimdDeclAttr::ConvertBranchStateTyToStr(BS) << BSRange;
IsError = true;
}
BS = Out;
BSRange = SourceRange(Tok.getLocation(), Tok.getEndLoc());
P.ConsumeToken();
} else if (ClauseName.equals("simdlen")) {
if (SimdLen.isUsable()) {
P.Diag(Tok, diag::err_omp_more_one_clause)
<< getOpenMPDirectiveName(OMPD_declare_simd) << ClauseName << 0;
IsError = true;
}
P.ConsumeToken();
SourceLocation RLoc;
SimdLen = P.ParseOpenMPParensExpr(ClauseName, RLoc);
if (SimdLen.isInvalid())
IsError = true;
} else {
OpenMPClauseKind CKind = getOpenMPClauseKind(ClauseName);
[OPENMP 4.0] Support for 'linear' clause in 'declare simd' directive. The linear clause declares one or more list items to be private to a SIMD lane and to have a linear relationship with respect to the iteration space of a loop. 'linear' '(' <linear-list> [ ':' <linear-step> ] ')' When a linear-step expression is specified in a linear clause it must be either a constant integer expression or an integer-typed parameter that is specified in a uniform clause on the directive. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266056
2016-04-12 19:02:11 +08:00
if (CKind == OMPC_uniform || CKind == OMPC_aligned ||
CKind == OMPC_linear) {
[OPENMP 4.0] Support for 'aligned' clause in 'declare simd' directive. The aligned clause declares that the object to which each list item points is aligned to the number of bytes expressed in the optional parameter of the aligned clause. 'aligned' '(' <argument-list> [ ':' <alignment> ] ')' The optional parameter of the aligned clause, alignment, must be a constant positive integer expression. If no optional parameter is specified, implementation-defined default alignments for SIMD instructions on the target platforms are assumed. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266052
2016-04-12 17:35:56 +08:00
Parser::OpenMPVarListDataTy Data;
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-24 03:53:05 +08:00
SmallVectorImpl<Expr *> *Vars = &Uniforms;
[OPENMP]Add extra checks and initialization for clause modifier. Added initialization of the extra modifier to silence sanitizer. Added extra checks to avoid such trouble in future.
2019-12-25 05:02:58 +08:00
if (CKind == OMPC_aligned) {
[OPENMP 4.0] Support for 'aligned' clause in 'declare simd' directive. The aligned clause declares that the object to which each list item points is aligned to the number of bytes expressed in the optional parameter of the aligned clause. 'aligned' '(' <argument-list> [ ':' <alignment> ] ')' The optional parameter of the aligned clause, alignment, must be a constant positive integer expression. If no optional parameter is specified, implementation-defined default alignments for SIMD instructions on the target platforms are assumed. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266052
2016-04-12 17:35:56 +08:00
Vars = &Aligneds;
[OPENMP]Add extra checks and initialization for clause modifier. Added initialization of the extra modifier to silence sanitizer. Added extra checks to avoid such trouble in future.
2019-12-25 05:02:58 +08:00
} else if (CKind == OMPC_linear) {
Data.ExtraModifier = OMPC_LINEAR_val;
[OPENMP 4.0] Support for 'linear' clause in 'declare simd' directive. The linear clause declares one or more list items to be private to a SIMD lane and to have a linear relationship with respect to the iteration space of a loop. 'linear' '(' <linear-list> [ ':' <linear-step> ] ')' When a linear-step expression is specified in a linear clause it must be either a constant integer expression or an integer-typed parameter that is specified in a uniform clause on the directive. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266056
2016-04-12 19:02:11 +08:00
Vars = &Linears;
[OPENMP]Add extra checks and initialization for clause modifier. Added initialization of the extra modifier to silence sanitizer. Added extra checks to avoid such trouble in future.
2019-12-25 05:02:58 +08:00
}
[OPENMP 4.0] Support for 'aligned' clause in 'declare simd' directive. The aligned clause declares that the object to which each list item points is aligned to the number of bytes expressed in the optional parameter of the aligned clause. 'aligned' '(' <argument-list> [ ':' <alignment> ] ')' The optional parameter of the aligned clause, alignment, must be a constant positive integer expression. If no optional parameter is specified, implementation-defined default alignments for SIMD instructions on the target platforms are assumed. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266052
2016-04-12 17:35:56 +08:00
P.ConsumeToken();
if (P.ParseOpenMPVarList(OMPD_declare_simd,
getOpenMPClauseKind(ClauseName), *Vars, Data))
IsError = true;
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-24 03:53:05 +08:00
if (CKind == OMPC_aligned) {
[OPENMP50]Add initial support for OpenMP 5.0 iterator. Added basic parsing/semantic analysis/(de)serialization support for iterator expression introduced in OpenMP 5.0.
2020-04-02 03:06:38 +08:00
Alignments.append(Aligneds.size() - Alignments.size(),
Data.DepModOrTailExpr);
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-24 03:53:05 +08:00
} else if (CKind == OMPC_linear) {
[OPENMP]Add extra checks and initialization for clause modifier. Added initialization of the extra modifier to silence sanitizer. Added extra checks to avoid such trouble in future.
2019-12-25 05:02:58 +08:00
assert(0 <= Data.ExtraModifier &&
Data.ExtraModifier <= OMPC_LINEAR_unknown &&
"Unexpected linear modifier.");
[OPENMP50]Basic support for conditional lastprivate. Added parsing/sema checks for conditional lastprivates.
2019-12-21 00:04:57 +08:00
if (P.getActions().CheckOpenMPLinearModifier(
static_cast<OpenMPLinearClauseKind>(Data.ExtraModifier),
[OPENMP50]Add 'default' modifier in reduction clauses. Added full support for 'default' modifier in the reduction clauses.
2020-03-24 05:30:38 +08:00
Data.ExtraModifierLoc))
[OPENMP50]Basic support for conditional lastprivate. Added parsing/sema checks for conditional lastprivates.
2019-12-21 00:04:57 +08:00
Data.ExtraModifier = OMPC_LINEAR_val;
[OPENMP 4.0] Support for 'linear' clause in 'declare simd' directive. The linear clause declares one or more list items to be private to a SIMD lane and to have a linear relationship with respect to the iteration space of a loop. 'linear' '(' <linear-list> [ ':' <linear-step> ] ')' When a linear-step expression is specified in a linear clause it must be either a constant integer expression or an integer-typed parameter that is specified in a uniform clause on the directive. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266056
2016-04-12 19:02:11 +08:00
LinModifiers.append(Linears.size() - LinModifiers.size(),
[OPENMP50]Basic support for conditional lastprivate. Added parsing/sema checks for conditional lastprivates.
2019-12-21 00:04:57 +08:00
Data.ExtraModifier);
[OPENMP50]Add initial support for OpenMP 5.0 iterator. Added basic parsing/semantic analysis/(de)serialization support for iterator expression introduced in OpenMP 5.0.
2020-04-02 03:06:38 +08:00
Steps.append(Linears.size() - Steps.size(), Data.DepModOrTailExpr);
[OPENMP 4.0] Support for 'linear' clause in 'declare simd' directive. The linear clause declares one or more list items to be private to a SIMD lane and to have a linear relationship with respect to the iteration space of a loop. 'linear' '(' <linear-list> [ ':' <linear-step> ] ')' When a linear-step expression is specified in a linear clause it must be either a constant integer expression or an integer-typed parameter that is specified in a uniform clause on the directive. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266056
2016-04-12 19:02:11 +08:00
}
[OPENMP 4.0] Support for 'aligned' clause in 'declare simd' directive. The aligned clause declares that the object to which each list item points is aligned to the number of bytes expressed in the optional parameter of the aligned clause. 'aligned' '(' <argument-list> [ ':' <alignment> ] ')' The optional parameter of the aligned clause, alignment, must be a constant positive integer expression. If no optional parameter is specified, implementation-defined default alignments for SIMD instructions on the target platforms are assumed. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266052
2016-04-12 17:35:56 +08:00
} else
// TODO: add parsing of other clauses.
break;
}
// Skip ',' if any.
if (Tok.is(tok::comma))
P.ConsumeToken();
}
return IsError;
}
[OPENMP 4.0] Parsing/sema analysis for 'simdlen' clause in 'declare simd' construct. OpenMP 4.0 defines '#pragma omp declare simd' construct that may have associated 'simdlen' clause with constant positive expression as an argument: simdlen(<const_expr>) Patch adds parsin and semantic analysis for simdlen clause. llvm-svn: 265668
2016-04-07 20:45:37 +08:00
/// Parse clauses for '#pragma omp declare simd'.
Parser::DeclGroupPtrTy
Parser::ParseOMPDeclareSimdClauses(Parser::DeclGroupPtrTy Ptr,
CachedTokens &Toks, SourceLocation Loc) {
[Lex] Allow to consume tokens while preprocessing Summary: By adding a hook to consume all tokens produced by the preprocessor. The intention of this change is to make it possible to consume the expanded tokens without re-runnig the preprocessor with minimal changes to the preprocessor and minimal performance penalty when preprocessing without recording the tokens. The added hook is very low-level and reconstructing the expanded token stream requires more work in the client code, the actual algorithm to collect the tokens using this hook can be found in the follow-up change. Reviewers: rsmith Reviewed By: rsmith Subscribers: eraman, nemanjai, kbarton, jsji, riccibruno, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D59885 llvm-svn: 361007
2019-05-17 17:32:05 +08:00
PP.EnterToken(Tok, /*IsReinject*/ true);
PP.EnterTokenStream(Toks, /*DisableMacroExpansion=*/true,
/*IsReinject*/ true);
[OPENMP 4.0] Parsing/sema analysis for 'simdlen' clause in 'declare simd' construct. OpenMP 4.0 defines '#pragma omp declare simd' construct that may have associated 'simdlen' clause with constant positive expression as an argument: simdlen(<const_expr>) Patch adds parsin and semantic analysis for simdlen clause. llvm-svn: 265668
2016-04-07 20:45:37 +08:00
// Consume the previously pushed token.
ConsumeAnyToken(/*ConsumeCodeCompletionTok=*/true);
[OPENMP5.0]Add basic support for declare variant directive. Added basic support for declare variant directive and its match clause with user context selector. llvm-svn: 371892
2019-09-14 04:18:17 +08:00
ConsumeAnyToken(/*ConsumeCodeCompletionTok=*/true);
[OPENMP 4.0] Parsing/sema analysis for 'simdlen' clause in 'declare simd' construct. OpenMP 4.0 defines '#pragma omp declare simd' construct that may have associated 'simdlen' clause with constant positive expression as an argument: simdlen(<const_expr>) Patch adds parsin and semantic analysis for simdlen clause. llvm-svn: 265668
2016-04-07 20:45:37 +08:00
FNContextRAII FnContext(*this, Ptr);
OMPDeclareSimdDeclAttr::BranchStateTy BS =
OMPDeclareSimdDeclAttr::BS_Undefined;
ExprResult Simdlen;
[OPENMP 4.0] Support for 'uniform' clause in 'declare simd' directive. OpenMP 4.0 defines clause 'uniform' in 'declare simd' directive: 'uniform' '(' <argument-list> ')' The uniform clause declares one or more arguments to have an invariant value for all concurrent invocations of the function in the execution of a single SIMD loop. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266041
2016-04-12 13:28:34 +08:00
SmallVector<Expr *, 4> Uniforms;
[OPENMP 4.0] Support for 'aligned' clause in 'declare simd' directive. The aligned clause declares that the object to which each list item points is aligned to the number of bytes expressed in the optional parameter of the aligned clause. 'aligned' '(' <argument-list> [ ':' <alignment> ] ')' The optional parameter of the aligned clause, alignment, must be a constant positive integer expression. If no optional parameter is specified, implementation-defined default alignments for SIMD instructions on the target platforms are assumed. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266052
2016-04-12 17:35:56 +08:00
SmallVector<Expr *, 4> Aligneds;
SmallVector<Expr *, 4> Alignments;
[OPENMP 4.0] Support for 'linear' clause in 'declare simd' directive. The linear clause declares one or more list items to be private to a SIMD lane and to have a linear relationship with respect to the iteration space of a loop. 'linear' '(' <linear-list> [ ':' <linear-step> ] ')' When a linear-step expression is specified in a linear clause it must be either a constant integer expression or an integer-typed parameter that is specified in a uniform clause on the directive. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266056
2016-04-12 19:02:11 +08:00
SmallVector<Expr *, 4> Linears;
SmallVector<unsigned, 4> LinModifiers;
SmallVector<Expr *, 4> Steps;
bool IsError =
parseDeclareSimdClauses(*this, BS, Simdlen, Uniforms, Aligneds,
Alignments, Linears, LinModifiers, Steps);
[OpenMP][NFC] Outline common functionality (skipUntilPragmaOpenMPEnd) The same code was repeated multiple times, we put it in a function now.
2020-02-22 03:48:56 +08:00
skipUntilPragmaOpenMPEnd(OMPD_declare_simd);
[OPENMP 4.0] Parsing/sema analysis for 'simdlen' clause in 'declare simd' construct. OpenMP 4.0 defines '#pragma omp declare simd' construct that may have associated 'simdlen' clause with constant positive expression as an argument: simdlen(<const_expr>) Patch adds parsin and semantic analysis for simdlen clause. llvm-svn: 265668
2016-04-07 20:45:37 +08:00
// Skip the last annot_pragma_openmp_end.
Fix the location of "missing ';'" suggestions after annotation tokens. We were incorrectly setting PrevTokLocation to the first token in the annotation token instead of the last when consuming it. To fix this without adding a complex switch to the hot path through ConsumeToken, we now have a ConsumeAnnotationToken function for consuming annotation tokens in addition to the other Consume*Token special case functions. llvm-svn: 303372
2017-05-19 03:21:48 +08:00
SourceLocation EndLoc = ConsumeAnnotationToken();
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-24 03:53:05 +08:00
if (IsError)
return Ptr;
return Actions.ActOnOpenMPDeclareSimdDirective(
Ptr, BS, Simdlen.get(), Uniforms, Aligneds, Alignments, Linears,
LinModifiers, Steps, SourceRange(Loc, EndLoc));
[OPENMP 4.0] Support for 'inbranch|noinbranch' clauses in 'declare simd'. Added parsing/semantic analysis for 'inbranch|notinbranch' clauses of '#pragma omp declare simd' construct. llvm-svn: 265287
2016-04-04 18:12:15 +08:00
}
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
namespace {
/// Constant used in the diagnostics to distinguish the levels in an OpenMP
/// contexts: selector-set={selector(trait, ...), ...}, ....
enum OMPContextLvl {
CONTEXT_SELECTOR_SET_LVL = 0,
CONTEXT_SELECTOR_LVL = 1,
CONTEXT_TRAIT_LVL = 2,
};
static StringRef stringLiteralParser(Parser &P) {
ExprResult Res = P.ParseStringLiteralExpression(true);
return Res.isUsable() ? Res.getAs<StringLiteral>()->getString() : "";
}
static StringRef getNameFromIdOrString(Parser &P, Token &Tok,
OMPContextLvl Lvl) {
[OpenMP] Support construct trait set for Clang This patch supports construct trait set selector by using the existed declare variant infrastructure inside `OMPContext` and simd selector is currently not supported. The goal of this patch is to pass the declare variant test inside sollve test suite. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D109635
2021-09-17 00:28:31 +08:00
if (Tok.is(tok::identifier) || Tok.is(tok::kw_for)) {
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
llvm::SmallString<16> Buffer;
StringRef Name = P.getPreprocessor().getSpelling(Tok, Buffer);
(void)P.ConsumeToken();
return Name;
}
if (tok::isStringLiteral(Tok.getKind()))
return stringLiteralParser(P);
P.Diag(Tok.getLocation(),
diag::warn_omp_declare_variant_string_literal_or_identifier)
<< Lvl;
return "";
}
static bool checkForDuplicates(Parser &P, StringRef Name,
SourceLocation NameLoc,
llvm::StringMap<SourceLocation> &Seen,
OMPContextLvl Lvl) {
auto Res = Seen.try_emplace(Name, NameLoc);
if (Res.second)
return false;
// Each trait-set-selector-name, trait-selector-name and trait-name can
// only be specified once.
P.Diag(NameLoc, diag::warn_omp_declare_variant_ctx_mutiple_use)
<< Lvl << Name;
P.Diag(Res.first->getValue(), diag::note_omp_declare_variant_ctx_used_here)
<< Lvl << Name;
return true;
}
} // namespace
[OpenMP][NFC] Clang format ParseOpenMP ParseOpenMP.cpp was pretty much clang-formatted except a few minor locations. Let's make it a clang formatted file. Reviewed By: JonChesterfield Differential Revision: https://reviews.llvm.org/D90440
2020-10-30 07:44:28 +08:00
void Parser::parseOMPTraitPropertyKind(OMPTraitProperty &TIProperty,
llvm::omp::TraitSet Set,
llvm::omp::TraitSelector Selector,
llvm::StringMap<SourceLocation> &Seen) {
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
TIProperty.Kind = TraitProperty::invalid;
SourceLocation NameLoc = Tok.getLocation();
[OpenMP][NFC] Clang format ParseOpenMP ParseOpenMP.cpp was pretty much clang-formatted except a few minor locations. Let's make it a clang formatted file. Reviewed By: JonChesterfield Differential Revision: https://reviews.llvm.org/D90440
2020-10-30 07:44:28 +08:00
StringRef Name = getNameFromIdOrString(*this, Tok, CONTEXT_TRAIT_LVL);
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
if (Name.empty()) {
Diag(Tok.getLocation(), diag::note_omp_declare_variant_ctx_options)
<< CONTEXT_TRAIT_LVL << listOpenMPContextTraitProperties(Set, Selector);
return;
}
[OpenMP] Allow traits for the OpenMP context selector `isa` It was unclear what `isa` was supposed to mean so we did not provide any traits for this context selector. With this patch we will allow *any* string or identifier. We use the target attribute and target info to determine if the trait matches. In other words, we will check if the provided value is a target feature that is available (at the call site). Fixes PR46338 Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D83281
2020-07-07 14:08:03 +08:00
TIProperty.RawString = Name;
TIProperty.Kind = getOpenMPContextTraitPropertyKind(Set, Selector, Name);
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
if (TIProperty.Kind != TraitProperty::invalid) {
if (checkForDuplicates(*this, Name, NameLoc, Seen, CONTEXT_TRAIT_LVL))
TIProperty.Kind = TraitProperty::invalid;
return;
}
// It follows diagnosis and helping notes.
// FIXME: We should move the diagnosis string generation into libFrontend.
Diag(NameLoc, diag::warn_omp_declare_variant_ctx_not_a_property)
<< Name << getOpenMPContextTraitSelectorName(Selector)
<< getOpenMPContextTraitSetName(Set);
TraitSet SetForName = getOpenMPContextTraitSetKind(Name);
if (SetForName != TraitSet::invalid) {
Diag(NameLoc, diag::note_omp_declare_variant_ctx_is_a)
<< Name << CONTEXT_SELECTOR_SET_LVL << CONTEXT_TRAIT_LVL;
Diag(NameLoc, diag::note_omp_declare_variant_ctx_try)
<< Name << "<selector-name>"
<< "(<property-name>)";
return;
}
TraitSelector SelectorForName = getOpenMPContextTraitSelectorKind(Name);
if (SelectorForName != TraitSelector::invalid) {
Diag(NameLoc, diag::note_omp_declare_variant_ctx_is_a)
<< Name << CONTEXT_SELECTOR_LVL << CONTEXT_TRAIT_LVL;
bool AllowsTraitScore = false;
bool RequiresProperty = false;
isValidTraitSelectorForTraitSet(
SelectorForName, getOpenMPContextTraitSetForSelector(SelectorForName),
AllowsTraitScore, RequiresProperty);
Diag(NameLoc, diag::note_omp_declare_variant_ctx_try)
<< getOpenMPContextTraitSetName(
getOpenMPContextTraitSetForSelector(SelectorForName))
<< Name << (RequiresProperty ? "(<property-name>)" : "");
return;
}
for (const auto &PotentialSet :
{TraitSet::construct, TraitSet::user, TraitSet::implementation,
TraitSet::device}) {
TraitProperty PropertyForName =
[OpenMP] Allow traits for the OpenMP context selector `isa` It was unclear what `isa` was supposed to mean so we did not provide any traits for this context selector. With this patch we will allow *any* string or identifier. We use the target attribute and target info to determine if the trait matches. In other words, we will check if the provided value is a target feature that is available (at the call site). Fixes PR46338 Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D83281
2020-07-07 14:08:03 +08:00
getOpenMPContextTraitPropertyKind(PotentialSet, Selector, Name);
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
if (PropertyForName == TraitProperty::invalid)
continue;
Diag(NameLoc, diag::note_omp_declare_variant_ctx_try)
<< getOpenMPContextTraitSetName(
getOpenMPContextTraitSetForProperty(PropertyForName))
<< getOpenMPContextTraitSelectorName(
getOpenMPContextTraitSelectorForProperty(PropertyForName))
<< ("(" + Name + ")").str();
return;
}
Diag(NameLoc, diag::note_omp_declare_variant_ctx_options)
<< CONTEXT_TRAIT_LVL << listOpenMPContextTraitProperties(Set, Selector);
}
[OpenMP] Add match_{all,any,none} declare variant selector extensions. By default, all traits in the OpenMP context selector have to match for it to be acceptable. Though, we sometimes want a single property out of multiple to match (=any) or no match at all (=none). We offer these choices as extensions via `implementation={extension(match_{all,any,none})}` to the user. The choice will affect the entire context selector not only the traits following the match property. The first user will be D75788. There we can replace ``` #pragma omp begin declare variant match(device={arch(nvptx64)}) #define __CUDA__ #include <__clang_cuda_cmath.h> // TODO: Hack until we support an extension to the match clause that allows "or". #undef __CLANG_CUDA_CMATH_H__ #undef __CUDA__ #pragma omp end declare variant #pragma omp begin declare variant match(device={arch(nvptx)}) #define __CUDA__ #include <__clang_cuda_cmath.h> #undef __CUDA__ #pragma omp end declare variant ``` with the much simpler ``` #pragma omp begin declare variant match(device={arch(nvptx, nvptx64)}, implementation={extension(match_any)}) #define __CUDA__ #include <__clang_cuda_cmath.h> #undef __CUDA__ #pragma omp end declare variant ``` Reviewed By: mikerice Differential Revision: https://reviews.llvm.org/D77414
2020-04-04 00:29:53 +08:00
static bool checkExtensionProperty(Parser &P, SourceLocation Loc,
OMPTraitProperty &TIProperty,
OMPTraitSelector &TISelector,
llvm::StringMap<SourceLocation> &Seen) {
assert(TISelector.Kind ==
llvm::omp::TraitSelector::implementation_extension &&
"Only for extension properties, e.g., "
"`implementation={extension(PROPERTY)}`");
if (TIProperty.Kind == TraitProperty::invalid)
return false;
[OpenMP] Context selector extensions for return value overloading This extension allows to declare variants in between `omp begin/end declare variant` that do not match the type of the existing function with that name. Without this extension we would not find a base function (with a compatible type), therefore create a new one, which would cause conflicting declarations. With this extension we will not create "missing" base functions, which basically renders these specializations harmless. They will be generated but never called. Reviewed By: JonChesterfield Differential Revision: https://reviews.llvm.org/D85878
2020-08-13 05:49:10 +08:00
if (TIProperty.Kind ==
TraitProperty::implementation_extension_disable_implicit_base)
return true;
[OpenMP] Context selector extensions for template functions With this extension the effects of `omp begin declare variant` will be applied to template function declarations. The behavior is opt-in and controlled by the `extension(allow_templates)` trait. While generally useful, this will enable us to implement complex math function calls by overloading the templates of the standard library with the ones in libc++. Reviewed By: JonChesterfield Differential Revision: https://reviews.llvm.org/D85735
2020-06-01 00:40:09 +08:00
if (TIProperty.Kind ==
TraitProperty::implementation_extension_allow_templates)
return true;
[OpenMP] Add match_{all,any,none} declare variant selector extensions. By default, all traits in the OpenMP context selector have to match for it to be acceptable. Though, we sometimes want a single property out of multiple to match (=any) or no match at all (=none). We offer these choices as extensions via `implementation={extension(match_{all,any,none})}` to the user. The choice will affect the entire context selector not only the traits following the match property. The first user will be D75788. There we can replace ``` #pragma omp begin declare variant match(device={arch(nvptx64)}) #define __CUDA__ #include <__clang_cuda_cmath.h> // TODO: Hack until we support an extension to the match clause that allows "or". #undef __CLANG_CUDA_CMATH_H__ #undef __CUDA__ #pragma omp end declare variant #pragma omp begin declare variant match(device={arch(nvptx)}) #define __CUDA__ #include <__clang_cuda_cmath.h> #undef __CUDA__ #pragma omp end declare variant ``` with the much simpler ``` #pragma omp begin declare variant match(device={arch(nvptx, nvptx64)}, implementation={extension(match_any)}) #define __CUDA__ #include <__clang_cuda_cmath.h> #undef __CUDA__ #pragma omp end declare variant ``` Reviewed By: mikerice Differential Revision: https://reviews.llvm.org/D77414
2020-04-04 00:29:53 +08:00
auto IsMatchExtension = [](OMPTraitProperty &TP) {
return (TP.Kind ==
llvm::omp::TraitProperty::implementation_extension_match_all ||
TP.Kind ==
llvm::omp::TraitProperty::implementation_extension_match_any ||
TP.Kind ==
llvm::omp::TraitProperty::implementation_extension_match_none);
};
if (IsMatchExtension(TIProperty)) {
for (OMPTraitProperty &SeenProp : TISelector.Properties)
if (IsMatchExtension(SeenProp)) {
P.Diag(Loc, diag::err_omp_variant_ctx_second_match_extension);
[OpenMP] Allow traits for the OpenMP context selector `isa` It was unclear what `isa` was supposed to mean so we did not provide any traits for this context selector. With this patch we will allow *any* string or identifier. We use the target attribute and target info to determine if the trait matches. In other words, we will check if the provided value is a target feature that is available (at the call site). Fixes PR46338 Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D83281
2020-07-07 14:08:03 +08:00
StringRef SeenName = llvm::omp::getOpenMPContextTraitPropertyName(
SeenProp.Kind, SeenProp.RawString);
[OpenMP] Add match_{all,any,none} declare variant selector extensions. By default, all traits in the OpenMP context selector have to match for it to be acceptable. Though, we sometimes want a single property out of multiple to match (=any) or no match at all (=none). We offer these choices as extensions via `implementation={extension(match_{all,any,none})}` to the user. The choice will affect the entire context selector not only the traits following the match property. The first user will be D75788. There we can replace ``` #pragma omp begin declare variant match(device={arch(nvptx64)}) #define __CUDA__ #include <__clang_cuda_cmath.h> // TODO: Hack until we support an extension to the match clause that allows "or". #undef __CLANG_CUDA_CMATH_H__ #undef __CUDA__ #pragma omp end declare variant #pragma omp begin declare variant match(device={arch(nvptx)}) #define __CUDA__ #include <__clang_cuda_cmath.h> #undef __CUDA__ #pragma omp end declare variant ``` with the much simpler ``` #pragma omp begin declare variant match(device={arch(nvptx, nvptx64)}, implementation={extension(match_any)}) #define __CUDA__ #include <__clang_cuda_cmath.h> #undef __CUDA__ #pragma omp end declare variant ``` Reviewed By: mikerice Differential Revision: https://reviews.llvm.org/D77414
2020-04-04 00:29:53 +08:00
SourceLocation SeenLoc = Seen[SeenName];
P.Diag(SeenLoc, diag::note_omp_declare_variant_ctx_used_here)
<< CONTEXT_TRAIT_LVL << SeenName;
return false;
}
return true;
}
llvm_unreachable("Unknown extension property!");
}
[OpenMP][NFC] Remove the need to include `OpenMPClause.h` See rational here: https://reviews.llvm.org/D76173#1922916 Time to compile Attr.h in isolation goes from 2.6s to 1.8s. Original patch by Johannes, plus some additions from Reid to fix some clang tooling targets. Effect on transitive includes is marginal, though: $ diff -u <(sort thedeps-before.txt) <(sort thedeps-after.txt) \ | grep '^[-+] ' | sort | uniq -c | sort -nr 104 - /usr/local/google/home/rnk/llvm-project/clang/include/clang/AST/OpenMPClause.h 87 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Frontend/OpenMP/OMPContext.h 19 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/ADT/SmallSet.h 19 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/ADT/SetVector.h 14 - /usr/include/c++/9/set ... Differential Revision: https://reviews.llvm.org/D76184
2020-04-04 03:35:30 +08:00
void Parser::parseOMPContextProperty(OMPTraitSelector &TISelector,
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
llvm::omp::TraitSet Set,
llvm::StringMap<SourceLocation> &Seen) {
assert(TISelector.Kind != TraitSelector::user_condition &&
"User conditions are special properties not handled here!");
SourceLocation PropertyLoc = Tok.getLocation();
[OpenMP][NFC] Remove the need to include `OpenMPClause.h` See rational here: https://reviews.llvm.org/D76173#1922916 Time to compile Attr.h in isolation goes from 2.6s to 1.8s. Original patch by Johannes, plus some additions from Reid to fix some clang tooling targets. Effect on transitive includes is marginal, though: $ diff -u <(sort thedeps-before.txt) <(sort thedeps-after.txt) \ | grep '^[-+] ' | sort | uniq -c | sort -nr 104 - /usr/local/google/home/rnk/llvm-project/clang/include/clang/AST/OpenMPClause.h 87 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Frontend/OpenMP/OMPContext.h 19 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/ADT/SmallSet.h 19 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/ADT/SetVector.h 14 - /usr/include/c++/9/set ... Differential Revision: https://reviews.llvm.org/D76184
2020-04-04 03:35:30 +08:00
OMPTraitProperty TIProperty;
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
parseOMPTraitPropertyKind(TIProperty, Set, TISelector.Kind, Seen);
[OpenMP] Add match_{all,any,none} declare variant selector extensions. By default, all traits in the OpenMP context selector have to match for it to be acceptable. Though, we sometimes want a single property out of multiple to match (=any) or no match at all (=none). We offer these choices as extensions via `implementation={extension(match_{all,any,none})}` to the user. The choice will affect the entire context selector not only the traits following the match property. The first user will be D75788. There we can replace ``` #pragma omp begin declare variant match(device={arch(nvptx64)}) #define __CUDA__ #include <__clang_cuda_cmath.h> // TODO: Hack until we support an extension to the match clause that allows "or". #undef __CLANG_CUDA_CMATH_H__ #undef __CUDA__ #pragma omp end declare variant #pragma omp begin declare variant match(device={arch(nvptx)}) #define __CUDA__ #include <__clang_cuda_cmath.h> #undef __CUDA__ #pragma omp end declare variant ``` with the much simpler ``` #pragma omp begin declare variant match(device={arch(nvptx, nvptx64)}, implementation={extension(match_any)}) #define __CUDA__ #include <__clang_cuda_cmath.h> #undef __CUDA__ #pragma omp end declare variant ``` Reviewed By: mikerice Differential Revision: https://reviews.llvm.org/D77414
2020-04-04 00:29:53 +08:00
if (TISelector.Kind == llvm::omp::TraitSelector::implementation_extension)
if (!checkExtensionProperty(*this, Tok.getLocation(), TIProperty,
TISelector, Seen))
TIProperty.Kind = TraitProperty::invalid;
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
// If we have an invalid property here we already issued a warning.
if (TIProperty.Kind == TraitProperty::invalid) {
if (PropertyLoc != Tok.getLocation())
Diag(Tok.getLocation(), diag::note_omp_declare_variant_ctx_continue_here)
<< CONTEXT_TRAIT_LVL;
return;
}
if (isValidTraitPropertyForTraitSetAndSelector(TIProperty.Kind,
TISelector.Kind, Set)) {
[OpenMP] Add match_{all,any,none} declare variant selector extensions. By default, all traits in the OpenMP context selector have to match for it to be acceptable. Though, we sometimes want a single property out of multiple to match (=any) or no match at all (=none). We offer these choices as extensions via `implementation={extension(match_{all,any,none})}` to the user. The choice will affect the entire context selector not only the traits following the match property. The first user will be D75788. There we can replace ``` #pragma omp begin declare variant match(device={arch(nvptx64)}) #define __CUDA__ #include <__clang_cuda_cmath.h> // TODO: Hack until we support an extension to the match clause that allows "or". #undef __CLANG_CUDA_CMATH_H__ #undef __CUDA__ #pragma omp end declare variant #pragma omp begin declare variant match(device={arch(nvptx)}) #define __CUDA__ #include <__clang_cuda_cmath.h> #undef __CUDA__ #pragma omp end declare variant ``` with the much simpler ``` #pragma omp begin declare variant match(device={arch(nvptx, nvptx64)}, implementation={extension(match_any)}) #define __CUDA__ #include <__clang_cuda_cmath.h> #undef __CUDA__ #pragma omp end declare variant ``` Reviewed By: mikerice Differential Revision: https://reviews.llvm.org/D77414
2020-04-04 00:29:53 +08:00
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
// If we make it here the property, selector, set, score, condition, ... are
// all valid (or have been corrected). Thus we can record the property.
TISelector.Properties.push_back(TIProperty);
return;
}
Diag(PropertyLoc, diag::warn_omp_ctx_incompatible_property_for_selector)
[OpenMP] Allow traits for the OpenMP context selector `isa` It was unclear what `isa` was supposed to mean so we did not provide any traits for this context selector. With this patch we will allow *any* string or identifier. We use the target attribute and target info to determine if the trait matches. In other words, we will check if the provided value is a target feature that is available (at the call site). Fixes PR46338 Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D83281
2020-07-07 14:08:03 +08:00
<< getOpenMPContextTraitPropertyName(TIProperty.Kind,
TIProperty.RawString)
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
<< getOpenMPContextTraitSelectorName(TISelector.Kind)
<< getOpenMPContextTraitSetName(Set);
Diag(PropertyLoc, diag::note_omp_ctx_compatible_set_and_selector_for_property)
[OpenMP] Allow traits for the OpenMP context selector `isa` It was unclear what `isa` was supposed to mean so we did not provide any traits for this context selector. With this patch we will allow *any* string or identifier. We use the target attribute and target info to determine if the trait matches. In other words, we will check if the provided value is a target feature that is available (at the call site). Fixes PR46338 Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D83281
2020-07-07 14:08:03 +08:00
<< getOpenMPContextTraitPropertyName(TIProperty.Kind,
TIProperty.RawString)
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
<< getOpenMPContextTraitSelectorName(
getOpenMPContextTraitSelectorForProperty(TIProperty.Kind))
<< getOpenMPContextTraitSetName(
getOpenMPContextTraitSetForProperty(TIProperty.Kind));
Diag(Tok.getLocation(), diag::note_omp_declare_variant_ctx_continue_here)
<< CONTEXT_TRAIT_LVL;
}
[OpenMP][NFC] Clang format ParseOpenMP ParseOpenMP.cpp was pretty much clang-formatted except a few minor locations. Let's make it a clang formatted file. Reviewed By: JonChesterfield Differential Revision: https://reviews.llvm.org/D90440
2020-10-30 07:44:28 +08:00
void Parser::parseOMPTraitSelectorKind(OMPTraitSelector &TISelector,
llvm::omp::TraitSet Set,
llvm::StringMap<SourceLocation> &Seen) {
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
TISelector.Kind = TraitSelector::invalid;
SourceLocation NameLoc = Tok.getLocation();
[OpenMP][NFC] Clang format ParseOpenMP ParseOpenMP.cpp was pretty much clang-formatted except a few minor locations. Let's make it a clang formatted file. Reviewed By: JonChesterfield Differential Revision: https://reviews.llvm.org/D90440
2020-10-30 07:44:28 +08:00
StringRef Name = getNameFromIdOrString(*this, Tok, CONTEXT_SELECTOR_LVL);
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
if (Name.empty()) {
Diag(Tok.getLocation(), diag::note_omp_declare_variant_ctx_options)
<< CONTEXT_SELECTOR_LVL << listOpenMPContextTraitSelectors(Set);
return;
}
TISelector.Kind = getOpenMPContextTraitSelectorKind(Name);
if (TISelector.Kind != TraitSelector::invalid) {
if (checkForDuplicates(*this, Name, NameLoc, Seen, CONTEXT_SELECTOR_LVL))
TISelector.Kind = TraitSelector::invalid;
return;
}
// It follows diagnosis and helping notes.
Diag(NameLoc, diag::warn_omp_declare_variant_ctx_not_a_selector)
<< Name << getOpenMPContextTraitSetName(Set);
TraitSet SetForName = getOpenMPContextTraitSetKind(Name);
if (SetForName != TraitSet::invalid) {
Diag(NameLoc, diag::note_omp_declare_variant_ctx_is_a)
<< Name << CONTEXT_SELECTOR_SET_LVL << CONTEXT_SELECTOR_LVL;
Diag(NameLoc, diag::note_omp_declare_variant_ctx_try)
<< Name << "<selector-name>"
<< "<property-name>";
return;
}
for (const auto &PotentialSet :
{TraitSet::construct, TraitSet::user, TraitSet::implementation,
TraitSet::device}) {
[OpenMP] Allow traits for the OpenMP context selector `isa` It was unclear what `isa` was supposed to mean so we did not provide any traits for this context selector. With this patch we will allow *any* string or identifier. We use the target attribute and target info to determine if the trait matches. In other words, we will check if the provided value is a target feature that is available (at the call site). Fixes PR46338 Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D83281
2020-07-07 14:08:03 +08:00
TraitProperty PropertyForName = getOpenMPContextTraitPropertyKind(
PotentialSet, TraitSelector::invalid, Name);
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
if (PropertyForName == TraitProperty::invalid)
continue;
Diag(NameLoc, diag::note_omp_declare_variant_ctx_is_a)
<< Name << CONTEXT_TRAIT_LVL << CONTEXT_SELECTOR_LVL;
Diag(NameLoc, diag::note_omp_declare_variant_ctx_try)
<< getOpenMPContextTraitSetName(
getOpenMPContextTraitSetForProperty(PropertyForName))
<< getOpenMPContextTraitSelectorName(
getOpenMPContextTraitSelectorForProperty(PropertyForName))
<< ("(" + Name + ")").str();
return;
}
Diag(NameLoc, diag::note_omp_declare_variant_ctx_options)
<< CONTEXT_SELECTOR_LVL << listOpenMPContextTraitSelectors(Set);
}
[OPENMP50]Add parsing/sema analysis for declare variant score. Context selectors may include optional score clause in format `score(<expr>):`, where `<expr>` must be a constant integer expression. Added parsing/sema analysis only. llvm-svn: 373502
2019-10-03 02:19:02 +08:00
/// Parse optional 'score' '(' <expr> ')' ':'.
static ExprResult parseContextScore(Parser &P) {
ExprResult ScoreExpr;
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
llvm::SmallString<16> Buffer;
[OPENMP50]Add parsing/sema analysis for declare variant score. Context selectors may include optional score clause in format `score(<expr>):`, where `<expr>` must be a constant integer expression. Added parsing/sema analysis only. llvm-svn: 373502
2019-10-03 02:19:02 +08:00
StringRef SelectorName =
P.getPreprocessor().getSpelling(P.getCurToken(), Buffer);
[OPENMP50]Simplify processing of context selector scores. If the context selector score was not specified, its value must be set to 0. Simplify the processing of unspecified scores + save memory in attribute representation.
2019-11-06 04:33:18 +08:00
if (!SelectorName.equals("score"))
[OPENMP50]Add parsing/sema analysis for declare variant score. Context selectors may include optional score clause in format `score(<expr>):`, where `<expr>` must be a constant integer expression. Added parsing/sema analysis only. llvm-svn: 373502
2019-10-03 02:19:02 +08:00
return ScoreExpr;
(void)P.ConsumeToken();
SourceLocation RLoc;
ScoreExpr = P.ParseOpenMPParensExpr(SelectorName, RLoc);
// Parse ':'
if (P.getCurToken().is(tok::colon))
(void)P.ConsumeAnyToken();
else
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
P.Diag(P.getCurToken(), diag::warn_omp_declare_variant_expected)
<< "':'"
<< "score expression";
[OPENMP50]Add parsing/sema analysis for declare variant score. Context selectors may include optional score clause in format `score(<expr>):`, where `<expr>` must be a constant integer expression. Added parsing/sema analysis only. llvm-svn: 373502
2019-10-03 02:19:02 +08:00
return ScoreExpr;
}
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
/// Parses an OpenMP context selector.
///
/// <trait-selector-name> ['('[<trait-score>] <trait-property> [, <t-p>]* ')']
void Parser::parseOMPContextSelector(
[OpenMP][NFC] Remove the need to include `OpenMPClause.h` See rational here: https://reviews.llvm.org/D76173#1922916 Time to compile Attr.h in isolation goes from 2.6s to 1.8s. Original patch by Johannes, plus some additions from Reid to fix some clang tooling targets. Effect on transitive includes is marginal, though: $ diff -u <(sort thedeps-before.txt) <(sort thedeps-after.txt) \ | grep '^[-+] ' | sort | uniq -c | sort -nr 104 - /usr/local/google/home/rnk/llvm-project/clang/include/clang/AST/OpenMPClause.h 87 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Frontend/OpenMP/OMPContext.h 19 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/ADT/SmallSet.h 19 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/ADT/SetVector.h 14 - /usr/include/c++/9/set ... Differential Revision: https://reviews.llvm.org/D76184
2020-04-04 03:35:30 +08:00
OMPTraitSelector &TISelector, llvm::omp::TraitSet Set,
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
llvm::StringMap<SourceLocation> &SeenSelectors) {
unsigned short OuterPC = ParenCount;
// If anything went wrong we issue an error or warning and then skip the rest
// of the selector. However, commas are ambiguous so we look for the nesting
// of parentheses here as well.
auto FinishSelector = [OuterPC, this]() -> void {
bool Done = false;
while (!Done) {
while (!SkipUntil({tok::r_brace, tok::r_paren, tok::comma,
tok::annot_pragma_openmp_end},
StopBeforeMatch))
;
if (Tok.is(tok::r_paren) && OuterPC > ParenCount)
(void)ConsumeParen();
if (OuterPC <= ParenCount) {
Done = true;
break;
[OPENMP50]Suppport for multiple vendors in the same vendor context selector. According to OpenMP 5.0, multiple vendors could be specified in the vendor context selector via ',' as a separator. llvm-svn: 373756
2019-10-04 23:58:45 +08:00
}
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
if (!Tok.is(tok::comma) && !Tok.is(tok::r_paren)) {
Done = true;
break;
[OPENMP50]Suppport for multiple vendors in the same vendor context selector. According to OpenMP 5.0, multiple vendors could be specified in the vendor context selector via ',' as a separator. llvm-svn: 373756
2019-10-04 23:58:45 +08:00
}
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
(void)ConsumeAnyToken();
}
Diag(Tok.getLocation(), diag::note_omp_declare_variant_ctx_continue_here)
<< CONTEXT_SELECTOR_LVL;
};
SourceLocation SelectorLoc = Tok.getLocation();
parseOMPTraitSelectorKind(TISelector, Set, SeenSelectors);
if (TISelector.Kind == TraitSelector::invalid)
return FinishSelector();
bool AllowsTraitScore = false;
bool RequiresProperty = false;
if (!isValidTraitSelectorForTraitSet(TISelector.Kind, Set, AllowsTraitScore,
RequiresProperty)) {
Diag(SelectorLoc, diag::warn_omp_ctx_incompatible_selector_for_set)
<< getOpenMPContextTraitSelectorName(TISelector.Kind)
<< getOpenMPContextTraitSetName(Set);
Diag(SelectorLoc, diag::note_omp_ctx_compatible_set_for_selector)
<< getOpenMPContextTraitSelectorName(TISelector.Kind)
<< getOpenMPContextTraitSetName(
getOpenMPContextTraitSetForSelector(TISelector.Kind))
<< RequiresProperty;
return FinishSelector();
[OPENMP50]Parsing/sema support for 'implementation/vendor' context selector. Added basic parsing/semantic support for 'implementation={vendor(<vendor>)}' context selector. llvm-svn: 372917
2019-09-26 03:43:37 +08:00
}
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
if (!RequiresProperty) {
TISelector.Properties.push_back(
[OpenMP] Allow traits for the OpenMP context selector `isa` It was unclear what `isa` was supposed to mean so we did not provide any traits for this context selector. With this patch we will allow *any* string or identifier. We use the target attribute and target info to determine if the trait matches. In other words, we will check if the provided value is a target feature that is available (at the call site). Fixes PR46338 Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D83281
2020-07-07 14:08:03 +08:00
{getOpenMPContextTraitPropertyForSelector(TISelector.Kind),
getOpenMPContextTraitSelectorName(TISelector.Kind)});
[OPENMP50]Parsing/sema support for 'implementation/vendor' context selector. Added basic parsing/semantic support for 'implementation={vendor(<vendor>)}' context selector. llvm-svn: 372917
2019-09-26 03:43:37 +08:00
return;
}
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
if (!Tok.is(tok::l_paren)) {
Diag(SelectorLoc, diag::warn_omp_ctx_selector_without_properties)
<< getOpenMPContextTraitSelectorName(TISelector.Kind)
<< getOpenMPContextTraitSetName(Set);
return FinishSelector();
}
if (TISelector.Kind == TraitSelector::user_condition) {
SourceLocation RLoc;
ExprResult Condition = ParseOpenMPParensExpr("user condition", RLoc);
if (!Condition.isUsable())
return FinishSelector();
TISelector.ScoreOrCondition = Condition.get();
[OpenMP] Allow traits for the OpenMP context selector `isa` It was unclear what `isa` was supposed to mean so we did not provide any traits for this context selector. With this patch we will allow *any* string or identifier. We use the target attribute and target info to determine if the trait matches. In other words, we will check if the provided value is a target feature that is available (at the call site). Fixes PR46338 Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D83281
2020-07-07 14:08:03 +08:00
TISelector.Properties.push_back(
{TraitProperty::user_condition_unknown, "<condition>"});
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
return;
}
BalancedDelimiterTracker BDT(*this, tok::l_paren,
tok::annot_pragma_openmp_end);
// Parse '('.
(void)BDT.consumeOpen();
[OpenMP] `omp begin/end declare variant` - part 1, parsing This is the first part extracted from D71179 and cleaned up. This patch provides parsing support for `omp begin/end declare variant`, as defined in OpenMP technical report 8 (TR8) [0]. A major purpose of this patch is to provide proper math.h/cmath support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D74941
2020-02-21 09:50:47 +08:00
SourceLocation ScoreLoc = Tok.getLocation();
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
ExprResult Score = parseContextScore(*this);
[OpenMP] `omp begin/end declare variant` - part 1, parsing This is the first part extracted from D71179 and cleaned up. This patch provides parsing support for `omp begin/end declare variant`, as defined in OpenMP technical report 8 (TR8) [0]. A major purpose of this patch is to provide proper math.h/cmath support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D74941
2020-02-21 09:50:47 +08:00
if (!AllowsTraitScore && !Score.isUnset()) {
if (Score.isUsable()) {
Diag(ScoreLoc, diag::warn_omp_ctx_incompatible_score_for_property)
<< getOpenMPContextTraitSelectorName(TISelector.Kind)
<< getOpenMPContextTraitSetName(Set) << Score.get();
} else {
Diag(ScoreLoc, diag::warn_omp_ctx_incompatible_score_for_property)
<< getOpenMPContextTraitSelectorName(TISelector.Kind)
<< getOpenMPContextTraitSetName(Set) << "<invalid>";
}
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
Score = ExprResult();
}
if (Score.isUsable())
TISelector.ScoreOrCondition = Score.get();
llvm::StringMap<SourceLocation> SeenProperties;
do {
parseOMPContextProperty(TISelector, Set, SeenProperties);
} while (TryConsumeToken(tok::comma));
// Parse ')'.
BDT.consumeClose();
[OPENMP50]Parsing/sema support for 'implementation/vendor' context selector. Added basic parsing/semantic support for 'implementation={vendor(<vendor>)}' context selector. llvm-svn: 372917
2019-09-26 03:43:37 +08:00
}
[OpenMP][NFC] Remove the need to include `OpenMPClause.h` See rational here: https://reviews.llvm.org/D76173#1922916 Time to compile Attr.h in isolation goes from 2.6s to 1.8s. Original patch by Johannes, plus some additions from Reid to fix some clang tooling targets. Effect on transitive includes is marginal, though: $ diff -u <(sort thedeps-before.txt) <(sort thedeps-after.txt) \ | grep '^[-+] ' | sort | uniq -c | sort -nr 104 - /usr/local/google/home/rnk/llvm-project/clang/include/clang/AST/OpenMPClause.h 87 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Frontend/OpenMP/OMPContext.h 19 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/ADT/SmallSet.h 19 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/ADT/SetVector.h 14 - /usr/include/c++/9/set ... Differential Revision: https://reviews.llvm.org/D76184
2020-04-04 03:35:30 +08:00
void Parser::parseOMPTraitSetKind(OMPTraitSet &TISet,
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
llvm::StringMap<SourceLocation> &Seen) {
TISet.Kind = TraitSet::invalid;
SourceLocation NameLoc = Tok.getLocation();
[OpenMP][NFC] Clang format ParseOpenMP ParseOpenMP.cpp was pretty much clang-formatted except a few minor locations. Let's make it a clang formatted file. Reviewed By: JonChesterfield Differential Revision: https://reviews.llvm.org/D90440
2020-10-30 07:44:28 +08:00
StringRef Name = getNameFromIdOrString(*this, Tok, CONTEXT_SELECTOR_SET_LVL);
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
if (Name.empty()) {
Diag(Tok.getLocation(), diag::note_omp_declare_variant_ctx_options)
<< CONTEXT_SELECTOR_SET_LVL << listOpenMPContextTraitSets();
[OPENMP50]Add device/kind context selector support. Summary: Added basic parsing/sema support for device/kind context selector. Reviewers: jdoerfert Subscribers: rampitec, aheejin, fedor.sergeev, simoncook, guansong, s.egerton, hfinkel, kkwli0, caomhin, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70245
2019-11-06 04:13:30 +08:00
return;
}
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
TISet.Kind = getOpenMPContextTraitSetKind(Name);
if (TISet.Kind != TraitSet::invalid) {
if (checkForDuplicates(*this, Name, NameLoc, Seen,
CONTEXT_SELECTOR_SET_LVL))
TISet.Kind = TraitSet::invalid;
return;
[OPENMP50]Add device/kind context selector support. Summary: Added basic parsing/sema support for device/kind context selector. Reviewers: jdoerfert Subscribers: rampitec, aheejin, fedor.sergeev, simoncook, guansong, s.egerton, hfinkel, kkwli0, caomhin, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70245
2019-11-06 04:13:30 +08:00
}
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
// It follows diagnosis and helping notes.
Diag(NameLoc, diag::warn_omp_declare_variant_ctx_not_a_set) << Name;
TraitSelector SelectorForName = getOpenMPContextTraitSelectorKind(Name);
if (SelectorForName != TraitSelector::invalid) {
Diag(NameLoc, diag::note_omp_declare_variant_ctx_is_a)
<< Name << CONTEXT_SELECTOR_LVL << CONTEXT_SELECTOR_SET_LVL;
bool AllowsTraitScore = false;
bool RequiresProperty = false;
isValidTraitSelectorForTraitSet(
SelectorForName, getOpenMPContextTraitSetForSelector(SelectorForName),
AllowsTraitScore, RequiresProperty);
Diag(NameLoc, diag::note_omp_declare_variant_ctx_try)
<< getOpenMPContextTraitSetName(
getOpenMPContextTraitSetForSelector(SelectorForName))
<< Name << (RequiresProperty ? "(<property-name>)" : "");
return;
}
for (const auto &PotentialSet :
{TraitSet::construct, TraitSet::user, TraitSet::implementation,
TraitSet::device}) {
[OpenMP] Allow traits for the OpenMP context selector `isa` It was unclear what `isa` was supposed to mean so we did not provide any traits for this context selector. With this patch we will allow *any* string or identifier. We use the target attribute and target info to determine if the trait matches. In other words, we will check if the provided value is a target feature that is available (at the call site). Fixes PR46338 Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D83281
2020-07-07 14:08:03 +08:00
TraitProperty PropertyForName = getOpenMPContextTraitPropertyKind(
PotentialSet, TraitSelector::invalid, Name);
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
if (PropertyForName == TraitProperty::invalid)
continue;
Diag(NameLoc, diag::note_omp_declare_variant_ctx_is_a)
<< Name << CONTEXT_TRAIT_LVL << CONTEXT_SELECTOR_SET_LVL;
Diag(NameLoc, diag::note_omp_declare_variant_ctx_try)
<< getOpenMPContextTraitSetName(
getOpenMPContextTraitSetForProperty(PropertyForName))
<< getOpenMPContextTraitSelectorName(
getOpenMPContextTraitSelectorForProperty(PropertyForName))
<< ("(" + Name + ")").str();
return;
}
Diag(NameLoc, diag::note_omp_declare_variant_ctx_options)
<< CONTEXT_SELECTOR_SET_LVL << listOpenMPContextTraitSets();
}
/// Parses an OpenMP context selector set.
///
/// <trait-set-selector-name> '=' '{' <trait-selector> [, <trait-selector>]* '}'
void Parser::parseOMPContextSelectorSet(
[OpenMP][NFC] Clang format ParseOpenMP ParseOpenMP.cpp was pretty much clang-formatted except a few minor locations. Let's make it a clang formatted file. Reviewed By: JonChesterfield Differential Revision: https://reviews.llvm.org/D90440
2020-10-30 07:44:28 +08:00
OMPTraitSet &TISet, llvm::StringMap<SourceLocation> &SeenSets) {
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
auto OuterBC = BraceCount;
// If anything went wrong we issue an error or warning and then skip the rest
// of the set. However, commas are ambiguous so we look for the nesting
// of braces here as well.
auto FinishSelectorSet = [this, OuterBC]() -> void {
bool Done = false;
while (!Done) {
while (!SkipUntil({tok::comma, tok::r_brace, tok::r_paren,
tok::annot_pragma_openmp_end},
StopBeforeMatch))
;
if (Tok.is(tok::r_brace) && OuterBC > BraceCount)
(void)ConsumeBrace();
if (OuterBC <= BraceCount) {
Done = true;
break;
[OPENMP50]Add device/kind context selector support. Summary: Added basic parsing/sema support for device/kind context selector. Reviewers: jdoerfert Subscribers: rampitec, aheejin, fedor.sergeev, simoncook, guansong, s.egerton, hfinkel, kkwli0, caomhin, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70245
2019-11-06 04:13:30 +08:00
}
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
if (!Tok.is(tok::comma) && !Tok.is(tok::r_brace)) {
Done = true;
break;
[OPENMP50]Add device/kind context selector support. Summary: Added basic parsing/sema support for device/kind context selector. Reviewers: jdoerfert Subscribers: rampitec, aheejin, fedor.sergeev, simoncook, guansong, s.egerton, hfinkel, kkwli0, caomhin, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70245
2019-11-06 04:13:30 +08:00
}
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
(void)ConsumeAnyToken();
}
Diag(Tok.getLocation(), diag::note_omp_declare_variant_ctx_continue_here)
<< CONTEXT_SELECTOR_SET_LVL;
};
parseOMPTraitSetKind(TISet, SeenSets);
if (TISet.Kind == TraitSet::invalid)
return FinishSelectorSet();
// Parse '='.
if (!TryConsumeToken(tok::equal))
Diag(Tok.getLocation(), diag::warn_omp_declare_variant_expected)
<< "="
<< ("context set name \"" + getOpenMPContextTraitSetName(TISet.Kind) +
"\"")
.str();
// Parse '{'.
if (Tok.is(tok::l_brace)) {
(void)ConsumeBrace();
} else {
Diag(Tok.getLocation(), diag::warn_omp_declare_variant_expected)
<< "{"
<< ("'=' that follows the context set name \"" +
getOpenMPContextTraitSetName(TISet.Kind) + "\"")
.str();
[OPENMP50]Add device/kind context selector support. Summary: Added basic parsing/sema support for device/kind context selector. Reviewers: jdoerfert Subscribers: rampitec, aheejin, fedor.sergeev, simoncook, guansong, s.egerton, hfinkel, kkwli0, caomhin, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70245
2019-11-06 04:13:30 +08:00
}
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
llvm::StringMap<SourceLocation> SeenSelectors;
do {
[OpenMP][NFC] Remove the need to include `OpenMPClause.h` See rational here: https://reviews.llvm.org/D76173#1922916 Time to compile Attr.h in isolation goes from 2.6s to 1.8s. Original patch by Johannes, plus some additions from Reid to fix some clang tooling targets. Effect on transitive includes is marginal, though: $ diff -u <(sort thedeps-before.txt) <(sort thedeps-after.txt) \ | grep '^[-+] ' | sort | uniq -c | sort -nr 104 - /usr/local/google/home/rnk/llvm-project/clang/include/clang/AST/OpenMPClause.h 87 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Frontend/OpenMP/OMPContext.h 19 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/ADT/SmallSet.h 19 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/ADT/SetVector.h 14 - /usr/include/c++/9/set ... Differential Revision: https://reviews.llvm.org/D76184
2020-04-04 03:35:30 +08:00
OMPTraitSelector TISelector;
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
parseOMPContextSelector(TISelector, TISet.Kind, SeenSelectors);
if (TISelector.Kind != TraitSelector::invalid &&
!TISelector.Properties.empty())
TISet.Selectors.push_back(TISelector);
} while (TryConsumeToken(tok::comma));
// Parse '}'.
if (Tok.is(tok::r_brace)) {
(void)ConsumeBrace();
} else {
Diag(Tok.getLocation(), diag::warn_omp_declare_variant_expected)
<< "}"
<< ("context selectors for the context set \"" +
getOpenMPContextTraitSetName(TISet.Kind) + "\"")
.str();
[OPENMP50]Add device/kind context selector support. Summary: Added basic parsing/sema support for device/kind context selector. Reviewers: jdoerfert Subscribers: rampitec, aheejin, fedor.sergeev, simoncook, guansong, s.egerton, hfinkel, kkwli0, caomhin, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70245
2019-11-06 04:13:30 +08:00
}
}
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
/// Parse OpenMP context selectors:
///
/// <trait-set-selector> [, <trait-set-selector>]*
[OpenMP][NFC] Clang format ParseOpenMP ParseOpenMP.cpp was pretty much clang-formatted except a few minor locations. Let's make it a clang formatted file. Reviewed By: JonChesterfield Differential Revision: https://reviews.llvm.org/D90440
2020-10-30 07:44:28 +08:00
bool Parser::parseOMPContextSelectors(SourceLocation Loc, OMPTraitInfo &TI) {
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
llvm::StringMap<SourceLocation> SeenSets;
[OPENMP5.0]Allow multiple context selectors in the context selector sets. According to OpenMP 5.0, context selector set might include several context selectors, separated with commas. Patch fixes this problem. llvm-svn: 372235
2019-09-19 00:24:31 +08:00
do {
[OpenMP][NFC] Remove the need to include `OpenMPClause.h` See rational here: https://reviews.llvm.org/D76173#1922916 Time to compile Attr.h in isolation goes from 2.6s to 1.8s. Original patch by Johannes, plus some additions from Reid to fix some clang tooling targets. Effect on transitive includes is marginal, though: $ diff -u <(sort thedeps-before.txt) <(sort thedeps-after.txt) \ | grep '^[-+] ' | sort | uniq -c | sort -nr 104 - /usr/local/google/home/rnk/llvm-project/clang/include/clang/AST/OpenMPClause.h 87 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Frontend/OpenMP/OMPContext.h 19 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/ADT/SmallSet.h 19 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/ADT/SetVector.h 14 - /usr/include/c++/9/set ... Differential Revision: https://reviews.llvm.org/D76184
2020-04-04 03:35:30 +08:00
OMPTraitSet TISet;
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
parseOMPContextSelectorSet(TISet, SeenSets);
if (TISet.Kind != TraitSet::invalid && !TISet.Selectors.empty())
TI.Sets.push_back(TISet);
} while (TryConsumeToken(tok::comma));
[OPENMP5.0]Add basic support for declare variant directive. Added basic support for declare variant directive and its match clause with user context selector. llvm-svn: 371892
2019-09-14 04:18:17 +08:00
return false;
}
/// Parse clauses for '#pragma omp declare variant ( variant-func-id ) clause'.
[OPENMP5.0]Allow multiple context selectors in the context selector sets. According to OpenMP 5.0, context selector set might include several context selectors, separated with commas. Patch fixes this problem. llvm-svn: 372235
2019-09-19 00:24:31 +08:00
void Parser::ParseOMPDeclareVariantClauses(Parser::DeclGroupPtrTy Ptr,
CachedTokens &Toks,
SourceLocation Loc) {
[OPENMP5.0]Add basic support for declare variant directive. Added basic support for declare variant directive and its match clause with user context selector. llvm-svn: 371892
2019-09-14 04:18:17 +08:00
PP.EnterToken(Tok, /*IsReinject*/ true);
PP.EnterTokenStream(Toks, /*DisableMacroExpansion=*/true,
/*IsReinject*/ true);
// Consume the previously pushed token.
ConsumeAnyToken(/*ConsumeCodeCompletionTok=*/true);
ConsumeAnyToken(/*ConsumeCodeCompletionTok=*/true);
FNContextRAII FnContext(*this, Ptr);
// Parse function declaration id.
SourceLocation RLoc;
// Parse with IsAddressOfOperand set to true to parse methods as DeclRefExprs
// instead of MemberExprs.
[OPENMP50]Do not mark the function as used if referenced only in declare variant directive. If the function is used only in declare variant directive as a variant function, it should not be marked as used to prevent emission of the target-specific functions. Build the reference in the unevaluated context.
2019-12-11 05:12:53 +08:00
ExprResult AssociatedFunction;
{
// Do not mark function as is used to prevent its emission if this is the
// only place where it is used.
EnterExpressionEvaluationContext Unevaluated(
Actions, Sema::ExpressionEvaluationContext::Unevaluated);
AssociatedFunction = ParseOpenMPParensExpr(
getOpenMPDirectiveName(OMPD_declare_variant), RLoc,
/*IsAddressOfOperand=*/true);
}
[OPENMP5.0]Add basic support for declare variant directive. Added basic support for declare variant directive and its match clause with user context selector. llvm-svn: 371892
2019-09-14 04:18:17 +08:00
if (!AssociatedFunction.isUsable()) {
if (!Tok.is(tok::annot_pragma_openmp_end))
while (!SkipUntil(tok::annot_pragma_openmp_end, StopBeforeMatch))
;
// Skip the last annot_pragma_openmp_end.
(void)ConsumeAnnotationToken();
[OPENMP5.0]Allow multiple context selectors in the context selector sets. According to OpenMP 5.0, context selector set might include several context selectors, separated with commas. Patch fixes this problem. llvm-svn: 372235
2019-09-19 00:24:31 +08:00
return;
[OPENMP5.0]Add basic support for declare variant directive. Added basic support for declare variant directive and its match clause with user context selector. llvm-svn: 371892
2019-09-14 04:18:17 +08:00
}
[OpenMP] Support nested OpenMP context selectors (declare variant) Due to `omp begin/end declare variant`, OpenMP context selectors can be nested. This patch adds initial support for this so we can use it for target math variants. We should improve the detection of "equivalent" scores and user conditions, we should also revisit the data structures of the OMPTraitInfo object, however, both are not pressing issues right now. Reviewed By: JonChesterfield Differential Revision: https://reviews.llvm.org/D85877
2020-08-13 14:05:51 +08:00
OMPTraitInfo *ParentTI = Actions.getOMPTraitInfoForSurroundingScope();
ASTContext &ASTCtx = Actions.getASTContext();
OMPTraitInfo &TI = ASTCtx.getNewOMPTraitInfo();
[OPENMP51]Initial parsing/sema for adjust_args clause for 'declare variant' Adds initial parsing and sema for the 'adjust_args' clause. Note that an AST clause is not created as it instead adds its expressions to the OMPDeclareVariantAttr. Differential Revision: https://reviews.llvm.org/D99905
2021-10-13 05:55:00 +08:00
SmallVector<Expr *, 6> AdjustNothing;
SmallVector<Expr *, 6> AdjustNeedDevicePtr;
[OPENMP51]Initial parsing/sema for append_args clause for 'declare variant' Adds initial parsing and sema for the 'append_args' clause. Note that an AST clause is not created as it instead adds its values to the OMPDeclareVariantAttr. Differential Revision: https://reviews.llvm.org/D111854
2021-10-15 05:28:51 +08:00
SmallVector<OMPDeclareVariantAttr::InteropType, 3> AppendArgs;
SourceLocation AdjustArgsLoc, AppendArgsLoc;
[OPENMP51]Initial parsing/sema for adjust_args clause for 'declare variant' Adds initial parsing and sema for the 'adjust_args' clause. Note that an AST clause is not created as it instead adds its expressions to the OMPDeclareVariantAttr. Differential Revision: https://reviews.llvm.org/D99905
2021-10-13 05:55:00 +08:00
// At least one clause is required.
if (Tok.is(tok::annot_pragma_openmp_end)) {
Diag(Tok.getLocation(), diag::err_omp_declare_variant_wrong_clause)
<< (getLangOpts().OpenMP < 51 ? 0 : 1);
}
bool IsError = false;
while (Tok.isNot(tok::annot_pragma_openmp_end)) {
OpenMPClauseKind CKind = Tok.isAnnotation()
? OMPC_unknown
: getOpenMPClauseKind(PP.getSpelling(Tok));
if (!isAllowedClauseForDirective(OMPD_declare_variant, CKind,
getLangOpts().OpenMP)) {
Diag(Tok.getLocation(), diag::err_omp_declare_variant_wrong_clause)
<< (getLangOpts().OpenMP < 51 ? 0 : 1);
IsError = true;
}
if (!IsError) {
switch (CKind) {
case OMPC_match:
IsError = parseOMPDeclareVariantMatchClause(Loc, TI, ParentTI);
break;
case OMPC_adjust_args: {
[OPENMP51]Initial parsing/sema for append_args clause for 'declare variant' Adds initial parsing and sema for the 'append_args' clause. Note that an AST clause is not created as it instead adds its values to the OMPDeclareVariantAttr. Differential Revision: https://reviews.llvm.org/D111854
2021-10-15 05:28:51 +08:00
AdjustArgsLoc = Tok.getLocation();
[OPENMP51]Initial parsing/sema for adjust_args clause for 'declare variant' Adds initial parsing and sema for the 'adjust_args' clause. Note that an AST clause is not created as it instead adds its expressions to the OMPDeclareVariantAttr. Differential Revision: https://reviews.llvm.org/D99905
2021-10-13 05:55:00 +08:00
ConsumeToken();
Parser::OpenMPVarListDataTy Data;
SmallVector<Expr *> Vars;
IsError = ParseOpenMPVarList(OMPD_declare_variant, OMPC_adjust_args,
Vars, Data);
if (!IsError)
llvm::append_range(Data.ExtraModifier == OMPC_ADJUST_ARGS_nothing
? AdjustNothing
: AdjustNeedDevicePtr,
Vars);
break;
}
[OPENMP51]Initial parsing/sema for append_args clause for 'declare variant' Adds initial parsing and sema for the 'append_args' clause. Note that an AST clause is not created as it instead adds its values to the OMPDeclareVariantAttr. Differential Revision: https://reviews.llvm.org/D111854
2021-10-15 05:28:51 +08:00
case OMPC_append_args:
if (!AppendArgs.empty()) {
Diag(AppendArgsLoc, diag::err_omp_more_one_clause)
<< getOpenMPDirectiveName(OMPD_declare_variant)
<< getOpenMPClauseName(CKind) << 0;
IsError = true;
}
if (!IsError) {
AppendArgsLoc = Tok.getLocation();
ConsumeToken();
IsError = parseOpenMPAppendArgs(AppendArgs);
}
break;
[OPENMP51]Initial parsing/sema for adjust_args clause for 'declare variant' Adds initial parsing and sema for the 'adjust_args' clause. Note that an AST clause is not created as it instead adds its expressions to the OMPDeclareVariantAttr. Differential Revision: https://reviews.llvm.org/D99905
2021-10-13 05:55:00 +08:00
default:
llvm_unreachable("Unexpected clause for declare variant.");
}
}
if (IsError) {
while (!SkipUntil(tok::annot_pragma_openmp_end, StopBeforeMatch))
;
// Skip the last annot_pragma_openmp_end.
(void)ConsumeAnnotationToken();
return;
}
// Skip ',' if any.
if (Tok.is(tok::comma))
ConsumeToken();
}
[OpenMP] `omp begin/end declare variant` - part 1, parsing This is the first part extracted from D71179 and cleaned up. This patch provides parsing support for `omp begin/end declare variant`, as defined in OpenMP technical report 8 (TR8) [0]. A major purpose of this patch is to provide proper math.h/cmath support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D74941
2020-02-21 09:50:47 +08:00
Optional<std::pair<FunctionDecl *, Expr *>> DeclVarData =
Actions.checkOpenMPDeclareVariantFunction(
[OPENMP51]Initial parsing/sema for append_args clause for 'declare variant' Adds initial parsing and sema for the 'append_args' clause. Note that an AST clause is not created as it instead adds its values to the OMPDeclareVariantAttr. Differential Revision: https://reviews.llvm.org/D111854
2021-10-15 05:28:51 +08:00
Ptr, AssociatedFunction.get(), TI, AppendArgs.size(),
[OpenMP] `omp begin/end declare variant` - part 1, parsing This is the first part extracted from D71179 and cleaned up. This patch provides parsing support for `omp begin/end declare variant`, as defined in OpenMP technical report 8 (TR8) [0]. A major purpose of this patch is to provide proper math.h/cmath support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D74941
2020-02-21 09:50:47 +08:00
SourceRange(Loc, Tok.getLocation()));
if (DeclVarData && !TI.Sets.empty())
Actions.ActOnOpenMPDeclareVariantDirective(
[OPENMP51]Initial parsing/sema for adjust_args clause for 'declare variant' Adds initial parsing and sema for the 'adjust_args' clause. Note that an AST clause is not created as it instead adds its expressions to the OMPDeclareVariantAttr. Differential Revision: https://reviews.llvm.org/D99905
2021-10-13 05:55:00 +08:00
DeclVarData->first, DeclVarData->second, TI, AdjustNothing,
[OPENMP51]Initial parsing/sema for append_args clause for 'declare variant' Adds initial parsing and sema for the 'append_args' clause. Note that an AST clause is not created as it instead adds its values to the OMPDeclareVariantAttr. Differential Revision: https://reviews.llvm.org/D111854
2021-10-15 05:28:51 +08:00
AdjustNeedDevicePtr, AppendArgs, AdjustArgsLoc, AppendArgsLoc,
SourceRange(Loc, Tok.getLocation()));
[OpenMP] `omp begin/end declare variant` - part 1, parsing This is the first part extracted from D71179 and cleaned up. This patch provides parsing support for `omp begin/end declare variant`, as defined in OpenMP technical report 8 (TR8) [0]. A major purpose of this patch is to provide proper math.h/cmath support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D74941
2020-02-21 09:50:47 +08:00
// Skip the last annot_pragma_openmp_end.
(void)ConsumeAnnotationToken();
}
[OPENMP51]Initial parsing/sema for append_args clause for 'declare variant' Adds initial parsing and sema for the 'append_args' clause. Note that an AST clause is not created as it instead adds its values to the OMPDeclareVariantAttr. Differential Revision: https://reviews.llvm.org/D111854
2021-10-15 05:28:51 +08:00
/// Parse a list of interop-types. These are 'target' and 'targetsync'. Both
/// are allowed but duplication of either is not meaningful.
static Optional<OMPDeclareVariantAttr::InteropType>
parseInteropTypeList(Parser &P) {
const Token &Tok = P.getCurToken();
bool HasError = false;
bool IsTarget = false;
bool IsTargetSync = false;
while (Tok.is(tok::identifier)) {
if (Tok.getIdentifierInfo()->isStr("target")) {
// OpenMP 5.1 [2.15.1, interop Construct, Restrictions]
// Each interop-type may be specified on an action-clause at most
// once.
if (IsTarget)
P.Diag(Tok, diag::warn_omp_more_one_interop_type) << "target";
IsTarget = true;
} else if (Tok.getIdentifierInfo()->isStr("targetsync")) {
if (IsTargetSync)
P.Diag(Tok, diag::warn_omp_more_one_interop_type) << "targetsync";
IsTargetSync = true;
} else {
HasError = true;
P.Diag(Tok, diag::err_omp_expected_interop_type);
}
P.ConsumeToken();
if (!Tok.is(tok::comma))
break;
P.ConsumeToken();
}
if (HasError)
return None;
if (!IsTarget && !IsTargetSync) {
P.Diag(Tok, diag::err_omp_expected_interop_type);
return None;
}
// As of OpenMP 5.1,there are two interop-types, "target" and
// "targetsync". Either or both are allowed for a single interop.
if (IsTarget && IsTargetSync)
return OMPDeclareVariantAttr::Target_TargetSync;
if (IsTarget)
return OMPDeclareVariantAttr::Target;
return OMPDeclareVariantAttr::TargetSync;
}
bool Parser::parseOpenMPAppendArgs(
SmallVectorImpl<OMPDeclareVariantAttr::InteropType> &InterOpTypes) {
bool HasError = false;
// Parse '('.
BalancedDelimiterTracker T(*this, tok::l_paren, tok::annot_pragma_openmp_end);
if (T.expectAndConsume(diag::err_expected_lparen_after,
getOpenMPClauseName(OMPC_append_args).data()))
return true;
// Parse the list of append-ops, each is;
// interop(interop-type[,interop-type]...)
while (Tok.is(tok::identifier) && Tok.getIdentifierInfo()->isStr("interop")) {
ConsumeToken();
BalancedDelimiterTracker IT(*this, tok::l_paren,
tok::annot_pragma_openmp_end);
if (IT.expectAndConsume(diag::err_expected_lparen_after, "interop"))
return true;
// Parse the interop-types.
if (Optional<OMPDeclareVariantAttr::InteropType> IType =
parseInteropTypeList(*this))
InterOpTypes.push_back(IType.getValue());
else
HasError = true;
IT.consumeClose();
if (Tok.is(tok::comma))
ConsumeToken();
}
if (!HasError && InterOpTypes.empty()) {
HasError = true;
Diag(Tok.getLocation(), diag::err_omp_unexpected_append_op);
SkipUntil(tok::comma, tok::r_paren, tok::annot_pragma_openmp_end,
StopBeforeMatch);
}
HasError = T.consumeClose() || HasError;
return HasError;
}
[OpenMP] `omp begin/end declare variant` - part 1, parsing This is the first part extracted from D71179 and cleaned up. This patch provides parsing support for `omp begin/end declare variant`, as defined in OpenMP technical report 8 (TR8) [0]. A major purpose of this patch is to provide proper math.h/cmath support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D74941
2020-02-21 09:50:47 +08:00
bool Parser::parseOMPDeclareVariantMatchClause(SourceLocation Loc,
[OpenMP] Support nested OpenMP context selectors (declare variant) Due to `omp begin/end declare variant`, OpenMP context selectors can be nested. This patch adds initial support for this so we can use it for target math variants. We should improve the detection of "equivalent" scores and user conditions, we should also revisit the data structures of the OMPTraitInfo object, however, both are not pressing issues right now. Reviewed By: JonChesterfield Differential Revision: https://reviews.llvm.org/D85877
2020-08-13 14:05:51 +08:00
OMPTraitInfo &TI,
OMPTraitInfo *ParentTI) {
[OPENMP5.0]Allow multiple context selectors in the context selector sets. According to OpenMP 5.0, context selector set might include several context selectors, separated with commas. Patch fixes this problem. llvm-svn: 372235
2019-09-19 00:24:31 +08:00
// Parse 'match'.
[OPENMP]Use standard parsing for 'match' clause, NFC. Reused standard clauses parsing scheme for parsing/matching 'match' clause in 'declare variant' directive. llvm-svn: 372635
2019-09-24 02:13:31 +08:00
OpenMPClauseKind CKind = Tok.isAnnotation()
? OMPC_unknown
: getOpenMPClauseKind(PP.getSpelling(Tok));
if (CKind != OMPC_match) {
[OPENMP5.0]Allow multiple context selectors in the context selector sets. According to OpenMP 5.0, context selector set might include several context selectors, separated with commas. Patch fixes this problem. llvm-svn: 372235
2019-09-19 00:24:31 +08:00
Diag(Tok.getLocation(), diag::err_omp_declare_variant_wrong_clause)
[OPENMP51]Initial parsing/sema for adjust_args clause for 'declare variant' Adds initial parsing and sema for the 'adjust_args' clause. Note that an AST clause is not created as it instead adds its expressions to the OMPDeclareVariantAttr. Differential Revision: https://reviews.llvm.org/D99905
2021-10-13 05:55:00 +08:00
<< (getLangOpts().OpenMP < 51 ? 0 : 1);
[OpenMP] `omp begin/end declare variant` - part 1, parsing This is the first part extracted from D71179 and cleaned up. This patch provides parsing support for `omp begin/end declare variant`, as defined in OpenMP technical report 8 (TR8) [0]. A major purpose of this patch is to provide proper math.h/cmath support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D74941
2020-02-21 09:50:47 +08:00
return true;
[OPENMP5.0]Add basic support for declare variant directive. Added basic support for declare variant directive and its match clause with user context selector. llvm-svn: 371892
2019-09-14 04:18:17 +08:00
}
[OPENMP5.0]Allow multiple context selectors in the context selector sets. According to OpenMP 5.0, context selector set might include several context selectors, separated with commas. Patch fixes this problem. llvm-svn: 372235
2019-09-19 00:24:31 +08:00
(void)ConsumeToken();
// Parse '('.
BalancedDelimiterTracker T(*this, tok::l_paren, tok::annot_pragma_openmp_end);
[OPENMP]Use standard parsing for 'match' clause, NFC. Reused standard clauses parsing scheme for parsing/matching 'match' clause in 'declare variant' directive. llvm-svn: 372635
2019-09-24 02:13:31 +08:00
if (T.expectAndConsume(diag::err_expected_lparen_after,
[OPENMP51]Initial parsing/sema for adjust_args clause for 'declare variant' Adds initial parsing and sema for the 'adjust_args' clause. Note that an AST clause is not created as it instead adds its expressions to the OMPDeclareVariantAttr. Differential Revision: https://reviews.llvm.org/D99905
2021-10-13 05:55:00 +08:00
getOpenMPClauseName(OMPC_match).data()))
[OpenMP] `omp begin/end declare variant` - part 1, parsing This is the first part extracted from D71179 and cleaned up. This patch provides parsing support for `omp begin/end declare variant`, as defined in OpenMP technical report 8 (TR8) [0]. A major purpose of this patch is to provide proper math.h/cmath support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D74941
2020-02-21 09:50:47 +08:00
return true;
[OPENMP5.0]Allow multiple context selectors in the context selector sets. According to OpenMP 5.0, context selector set might include several context selectors, separated with commas. Patch fixes this problem. llvm-svn: 372235
2019-09-19 00:24:31 +08:00
// Parse inner context selectors.
[FIX] Remove pointer in attribute to eliminate leaks (see D71830)
2020-02-16 08:07:42 +08:00
parseOMPContextSelectors(Loc, TI);
[OpenMP][Part 2] Use reusable OpenMP context/traits handling This patch implements an almost complete handling of OpenMP contexts/traits such that we can reuse most of the logic in Flang through the OMPContext.{h,cpp} in llvm/Frontend/OpenMP. All but construct SIMD specifiers, e.g., inbranch, and the device ISA selector are define in `llvm/lib/Frontend/OpenMP/OMPKinds.def`. From these definitions we generate the enum classes `TraitSet`, `TraitSelector`, and `TraitProperty` as well as conversion and helper functions in `llvm/lib/Frontend/OpenMP/OMPContext.{h,cpp}`. The above enum classes are used in the parser, sema, and the AST attribute. The latter is not a collection of multiple primitive variant arguments that contain encodings via numbers and strings but instead a tree that mirrors the `match` clause (see `struct OpenMPTraitInfo`). The changes to the parser make it more forgiving when wrong syntax is read and they also resulted in more specialized diagnostics. The tests are updated and the core issues are detected as before. Here and elsewhere this patch tries to be generic, thus we do not distinguish what selector set, selector, or property is parsed except if they do behave exceptionally, as for example `user={condition(EXPR)}` does. The sema logic changed in two ways: First, the OMPDeclareVariantAttr representation changed, as mentioned above, and the sema was adjusted to work with the new `OpenMPTraitInfo`. Second, the matching and scoring logic moved into `OMPContext.{h,cpp}`. It is implemented on a flat representation of the `match` clause that is not tied to clang. `OpenMPTraitInfo` provides a method to generate this flat structure (see `struct VariantMatchInfo`) by computing integer score values and boolean user conditions from the `clang::Expr` we keep for them. The OpenMP context is now an explicit object (see `struct OMPContext`). This is in anticipation of construct traits that need to be tracked. The OpenMP context, as well as the `VariantMatchInfo`, are basically made up of a set of active or respectively required traits, e.g., 'host', and an ordered container of constructs which allows duplication. Matching and scoring is kept as generic as possible to allow easy extension in the future. --- Test changes: The messages checked in `OpenMP/declare_variant_messages.{c,cpp}` have been auto generated to match the new warnings and notes of the parser. The "subset" checks were reversed causing the wrong version to be picked. The tests have been adjusted to correct this. We do not print scores if the user did not provide one. We print spaces to make lists in the `match` clause more legible. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: merge_guards_bot, rampitec, mgorny, hiraditya, aheejin, fedor.sergeev, simoncook, bollu, guansong, dexonsmith, jfb, s.egerton, llvm-commits, cfe-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71830
2019-12-20 10:42:12 +08:00
// Parse ')'
(void)T.consumeClose();
[OpenMP] Support nested OpenMP context selectors (declare variant) Due to `omp begin/end declare variant`, OpenMP context selectors can be nested. This patch adds initial support for this so we can use it for target math variants. We should improve the detection of "equivalent" scores and user conditions, we should also revisit the data structures of the OMPTraitInfo object, however, both are not pressing issues right now. Reviewed By: JonChesterfield Differential Revision: https://reviews.llvm.org/D85877
2020-08-13 14:05:51 +08:00
if (!ParentTI)
return false;
// Merge the parent/outer trait info into the one we just parsed and diagnose
Revert "[OpenMP] Introduce the `disable_selector_propagation` variant selector trait" Need to revert ad9e98b8efa0138559eb640023695dab54967a8d which this commit depends on. This reverts commit f771ef7b5f0ed260d00931cd50e6fe462edbacaf.
2021-03-12 13:47:10 +08:00
// problems.
[OpenMP] Support nested OpenMP context selectors (declare variant) Due to `omp begin/end declare variant`, OpenMP context selectors can be nested. This patch adds initial support for this so we can use it for target math variants. We should improve the detection of "equivalent" scores and user conditions, we should also revisit the data structures of the OMPTraitInfo object, however, both are not pressing issues right now. Reviewed By: JonChesterfield Differential Revision: https://reviews.llvm.org/D85877
2020-08-13 14:05:51 +08:00
// TODO: Keep some source location in the TI to provide better diagnostics.
// TODO: Perform some kind of equivalence check on the condition and score
// expressions.
Revert "[OpenMP] Do not propagate match extensions to nested contexts" Two tests failed for some reason, need to investigate: https://lab.llvm.org/buildbot/#/builders/109/builds/10399 This reverts commit ad9e98b8efa0138559eb640023695dab54967a8d.
2021-03-12 13:47:19 +08:00
for (const OMPTraitSet &ParentSet : ParentTI->Sets) {
[OpenMP] Support nested OpenMP context selectors (declare variant) Due to `omp begin/end declare variant`, OpenMP context selectors can be nested. This patch adds initial support for this so we can use it for target math variants. We should improve the detection of "equivalent" scores and user conditions, we should also revisit the data structures of the OMPTraitInfo object, however, both are not pressing issues right now. Reviewed By: JonChesterfield Differential Revision: https://reviews.llvm.org/D85877
2020-08-13 14:05:51 +08:00
bool MergedSet = false;
for (OMPTraitSet &Set : TI.Sets) {
if (Set.Kind != ParentSet.Kind)
continue;
MergedSet = true;
for (const OMPTraitSelector &ParentSelector : ParentSet.Selectors) {
bool MergedSelector = false;
for (OMPTraitSelector &Selector : Set.Selectors) {
if (Selector.Kind != ParentSelector.Kind)
continue;
MergedSelector = true;
for (const OMPTraitProperty &ParentProperty :
ParentSelector.Properties) {
bool MergedProperty = false;
for (OMPTraitProperty &Property : Selector.Properties) {
// Ignore "equivalent" properties.
if (Property.Kind != ParentProperty.Kind)
continue;
// If the kind is the same but the raw string not, we don't want
// to skip out on the property.
MergedProperty |= Property.RawString == ParentProperty.RawString;
if (Property.RawString == ParentProperty.RawString &&
Selector.ScoreOrCondition == ParentSelector.ScoreOrCondition)
continue;
if (Selector.Kind == llvm::omp::TraitSelector::user_condition) {
Diag(Loc, diag::err_omp_declare_variant_nested_user_condition);
} else if (Selector.ScoreOrCondition !=
ParentSelector.ScoreOrCondition) {
Diag(Loc, diag::err_omp_declare_variant_duplicate_nested_trait)
<< getOpenMPContextTraitPropertyName(
ParentProperty.Kind, ParentProperty.RawString)
<< getOpenMPContextTraitSelectorName(ParentSelector.Kind)
<< getOpenMPContextTraitSetName(ParentSet.Kind);
}
}
if (!MergedProperty)
Selector.Properties.push_back(ParentProperty);
}
}
if (!MergedSelector)
Set.Selectors.push_back(ParentSelector);
}
}
if (!MergedSet)
TI.Sets.push_back(ParentSet);
}
[OpenMP] `omp begin/end declare variant` - part 1, parsing This is the first part extracted from D71179 and cleaned up. This patch provides parsing support for `omp begin/end declare variant`, as defined in OpenMP technical report 8 (TR8) [0]. A major purpose of this patch is to provide proper math.h/cmath support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D74941
2020-02-21 09:50:47 +08:00
return false;
[OPENMP5.0]Add basic support for declare variant directive. Added basic support for declare variant directive and its match clause with user context selector. llvm-svn: 371892
2019-09-14 04:18:17 +08:00
}
[OpenMP] Add initial support for `omp [begin/end] assumes` The `assumes` directive is an OpenMP 5.1 feature that allows the user to provide assumptions to the optimizer. Assumptions can refer to directives (`absent` and `contains` clauses), expressions (`holds` clause), or generic properties (`no_openmp_routines`, `ext_ABCD`, ...). The `assumes` spelling is used for assumptions in the global scope while `assume` is used for executable contexts with an associated structured block. This patch only implements the global spellings. While clauses with arguments are "accepted" by the parser, they will simply be ignored for now. The implementation lowers the assumptions directly to the `AssumptionAttr`. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D91980
2020-11-24 01:48:59 +08:00
/// `omp assumes` or `omp begin/end assumes` <clause> [[,]<clause>]...
/// where
///
/// clause:
/// 'ext_IMPL_DEFINED'
/// 'absent' '(' directive-name [, directive-name]* ')'
/// 'contains' '(' directive-name [, directive-name]* ')'
/// 'holds' '(' scalar-expression ')'
/// 'no_openmp'
/// 'no_openmp_routines'
/// 'no_parallelism'
///
void Parser::ParseOpenMPAssumesDirective(OpenMPDirectiveKind DKind,
SourceLocation Loc) {
[OpenMP] Encode `omp [...] assume[...]` assumptions with `omp[x]` prefix Since these assumptions are coming from OpenMP it makes sense to mark them as such in the generic IR encoding. Standardized assumptions will be named omp_ASSUMPTION_NAME and extensions will be named ompx_ASSUMPTION_NAME which is the OpenMP 5.2 syntax for "extensions" of any kind. This also matches what the OpenMP-Opt pass expects. Summarized, #pragma omp [...] assume[s] no_parallelism now generates the same IR assumption annotation as __attribute__((assume("omp_no_parallelism"))) Reviewed By: jhuber6 Differential Revision: https://reviews.llvm.org/D105937
2021-07-14 04:35:58 +08:00
SmallVector<std::string, 4> Assumptions;
[OpenMP] Add initial support for `omp [begin/end] assumes` The `assumes` directive is an OpenMP 5.1 feature that allows the user to provide assumptions to the optimizer. Assumptions can refer to directives (`absent` and `contains` clauses), expressions (`holds` clause), or generic properties (`no_openmp_routines`, `ext_ABCD`, ...). The `assumes` spelling is used for assumptions in the global scope while `assume` is used for executable contexts with an associated structured block. This patch only implements the global spellings. While clauses with arguments are "accepted" by the parser, they will simply be ignored for now. The implementation lowers the assumptions directly to the `AssumptionAttr`. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D91980
2020-11-24 01:48:59 +08:00
bool SkippedClauses = false;
auto SkipBraces = [&](llvm::StringRef Spelling, bool IssueNote) {
BalancedDelimiterTracker T(*this, tok::l_paren,
tok::annot_pragma_openmp_end);
if (T.expectAndConsume(diag::err_expected_lparen_after, Spelling.data()))
return;
T.skipToEnd();
if (IssueNote && T.getCloseLocation().isValid())
Diag(T.getCloseLocation(),
diag::note_omp_assumption_clause_continue_here);
};
/// Helper to determine which AssumptionClauseMapping (ACM) in the
/// AssumptionClauseMappings table matches \p RawString. The return value is
/// the index of the matching ACM into the table or -1 if there was no match.
auto MatchACMClause = [&](StringRef RawString) {
llvm::StringSwitch<int> SS(RawString);
unsigned ACMIdx = 0;
for (const AssumptionClauseMappingInfo &ACMI : AssumptionClauseMappings) {
if (ACMI.StartsWith)
SS.StartsWith(ACMI.Identifier, ACMIdx++);
else
SS.Case(ACMI.Identifier, ACMIdx++);
}
return SS.Default(-1);
};
while (Tok.isNot(tok::annot_pragma_openmp_end)) {
IdentifierInfo *II = nullptr;
SourceLocation StartLoc = Tok.getLocation();
int Idx = -1;
if (Tok.isAnyIdentifier()) {
II = Tok.getIdentifierInfo();
Idx = MatchACMClause(II->getName());
}
ConsumeAnyToken();
bool NextIsLPar = Tok.is(tok::l_paren);
// Handle unknown clauses by skipping them.
if (Idx == -1) {
Diag(StartLoc, diag::warn_omp_unknown_assumption_clause_missing_id)
<< llvm::omp::getOpenMPDirectiveName(DKind)
<< llvm::omp::getAllAssumeClauseOptions() << NextIsLPar;
if (NextIsLPar)
SkipBraces(II ? II->getName() : "", /* IssueNote */ true);
SkippedClauses = true;
continue;
}
const AssumptionClauseMappingInfo &ACMI = AssumptionClauseMappings[Idx];
if (ACMI.HasDirectiveList || ACMI.HasExpression) {
// TODO: We ignore absent, contains, and holds assumptions for now. We
// also do not verify the content in the parenthesis at all.
SkippedClauses = true;
SkipBraces(II->getName(), /* IssueNote */ false);
continue;
}
if (NextIsLPar) {
Diag(Tok.getLocation(),
diag::warn_omp_unknown_assumption_clause_without_args)
<< II;
SkipBraces(II->getName(), /* IssueNote */ true);
}
assert(II && "Expected an identifier clause!");
[OpenMP] Encode `omp [...] assume[...]` assumptions with `omp[x]` prefix Since these assumptions are coming from OpenMP it makes sense to mark them as such in the generic IR encoding. Standardized assumptions will be named omp_ASSUMPTION_NAME and extensions will be named ompx_ASSUMPTION_NAME which is the OpenMP 5.2 syntax for "extensions" of any kind. This also matches what the OpenMP-Opt pass expects. Summarized, #pragma omp [...] assume[s] no_parallelism now generates the same IR assumption annotation as __attribute__((assume("omp_no_parallelism"))) Reviewed By: jhuber6 Differential Revision: https://reviews.llvm.org/D105937
2021-07-14 04:35:58 +08:00
std::string Assumption = II->getName().str();
[OpenMP] Add initial support for `omp [begin/end] assumes` The `assumes` directive is an OpenMP 5.1 feature that allows the user to provide assumptions to the optimizer. Assumptions can refer to directives (`absent` and `contains` clauses), expressions (`holds` clause), or generic properties (`no_openmp_routines`, `ext_ABCD`, ...). The `assumes` spelling is used for assumptions in the global scope while `assume` is used for executable contexts with an associated structured block. This patch only implements the global spellings. While clauses with arguments are "accepted" by the parser, they will simply be ignored for now. The implementation lowers the assumptions directly to the `AssumptionAttr`. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D91980
2020-11-24 01:48:59 +08:00
if (ACMI.StartsWith)
[OpenMP] Encode `omp [...] assume[...]` assumptions with `omp[x]` prefix Since these assumptions are coming from OpenMP it makes sense to mark them as such in the generic IR encoding. Standardized assumptions will be named omp_ASSUMPTION_NAME and extensions will be named ompx_ASSUMPTION_NAME which is the OpenMP 5.2 syntax for "extensions" of any kind. This also matches what the OpenMP-Opt pass expects. Summarized, #pragma omp [...] assume[s] no_parallelism now generates the same IR assumption annotation as __attribute__((assume("omp_no_parallelism"))) Reviewed By: jhuber6 Differential Revision: https://reviews.llvm.org/D105937
2021-07-14 04:35:58 +08:00
Assumption = "ompx_" + Assumption.substr(ACMI.Identifier.size());
else
Assumption = "omp_" + Assumption;
[OpenMP] Add initial support for `omp [begin/end] assumes` The `assumes` directive is an OpenMP 5.1 feature that allows the user to provide assumptions to the optimizer. Assumptions can refer to directives (`absent` and `contains` clauses), expressions (`holds` clause), or generic properties (`no_openmp_routines`, `ext_ABCD`, ...). The `assumes` spelling is used for assumptions in the global scope while `assume` is used for executable contexts with an associated structured block. This patch only implements the global spellings. While clauses with arguments are "accepted" by the parser, they will simply be ignored for now. The implementation lowers the assumptions directly to the `AssumptionAttr`. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D91980
2020-11-24 01:48:59 +08:00
Assumptions.push_back(Assumption);
}
Actions.ActOnOpenMPAssumesDirective(Loc, DKind, Assumptions, SkippedClauses);
}
void Parser::ParseOpenMPEndAssumesDirective(SourceLocation Loc) {
if (Actions.isInOpenMPAssumeScope())
Actions.ActOnOpenMPEndAssumesDirective();
else
Diag(Loc, diag::err_expected_begin_assumes);
}
[OPENMP5.0]Add support for device_type clause in declare target construct. OpenMP 5.0 introduced new clause for declare target directive, device_type clause, which may accept values host, nohost, and any. Host means that the function must be emitted only for the host, nohost - only for the device, and any - for both, device and the host. llvm-svn: 369775
2019-08-24 00:11:14 +08:00
/// Parsing of simple OpenMP clauses like 'default' or 'proc_bind'.
///
/// default-clause:
[OpenMP] Add firstprivate as a default data-sharing attribute to clang This implements the default(firstprivate) clause as defined in OpenMP Technical Report 8 (2.22.4). Reviewed By: jdoerfert, ABataev Differential Revision: https://reviews.llvm.org/D75591
2020-07-13 11:19:40 +08:00
/// 'default' '(' 'none' | 'shared' | 'firstprivate' ')
[OPENMP5.0]Add support for device_type clause in declare target construct. OpenMP 5.0 introduced new clause for declare target directive, device_type clause, which may accept values host, nohost, and any. Host means that the function must be emitted only for the host, nohost - only for the device, and any - for both, device and the host. llvm-svn: 369775
2019-08-24 00:11:14 +08:00
///
/// proc_bind-clause:
/// 'proc_bind' '(' 'master' | 'close' | 'spread' ')
///
/// device_type-clause:
/// 'device_type' '(' 'host' | 'nohost' | 'any' )'
namespace {
[OpenMP][NFC] Clang format ParseOpenMP ParseOpenMP.cpp was pretty much clang-formatted except a few minor locations. Let's make it a clang formatted file. Reviewed By: JonChesterfield Differential Revision: https://reviews.llvm.org/D90440
2020-10-30 07:44:28 +08:00
struct SimpleClauseData {
unsigned Type;
SourceLocation Loc;
SourceLocation LOpen;
SourceLocation TypeLoc;
SourceLocation RLoc;
SimpleClauseData(unsigned Type, SourceLocation Loc, SourceLocation LOpen,
SourceLocation TypeLoc, SourceLocation RLoc)
: Type(Type), Loc(Loc), LOpen(LOpen), TypeLoc(TypeLoc), RLoc(RLoc) {}
};
[OPENMP5.0]Add support for device_type clause in declare target construct. OpenMP 5.0 introduced new clause for declare target directive, device_type clause, which may accept values host, nohost, and any. Host means that the function must be emitted only for the host, nohost - only for the device, and any - for both, device and the host. llvm-svn: 369775
2019-08-24 00:11:14 +08:00
} // anonymous namespace
static Optional<SimpleClauseData>
parseOpenMPSimpleClause(Parser &P, OpenMPClauseKind Kind) {
const Token &Tok = P.getCurToken();
SourceLocation Loc = Tok.getLocation();
SourceLocation LOpen = P.ConsumeToken();
// Parse '('.
BalancedDelimiterTracker T(P, tok::l_paren, tok::annot_pragma_openmp_end);
if (T.expectAndConsume(diag::err_expected_lparen_after,
[OpenMP][NFCI] Move OpenMP clause information to `lib/Frontend/OpenMP` This is a cleanup and normalization patch that also enables reuse with Flang later on. A follow up will clean up and move the directive -> clauses mapping. Reviewed By: fghanim Differential Revision: https://reviews.llvm.org/D77112
2020-03-31 08:58:40 +08:00
getOpenMPClauseName(Kind).data()))
[OPENMP5.0]Add support for device_type clause in declare target construct. OpenMP 5.0 introduced new clause for declare target directive, device_type clause, which may accept values host, nohost, and any. Host means that the function must be emitted only for the host, nohost - only for the device, and any - for both, device and the host. llvm-svn: 369775
2019-08-24 00:11:14 +08:00
return llvm::None;
unsigned Type = getOpenMPSimpleClauseType(
[OpenMP] Implement TR8 `present` map type modifier in Clang (1/2) This patch implements Clang front end support for the OpenMP TR8 `present` map type modifier. The next patch in this series implements OpenMP runtime support. This patch does not attempt to implement TR8 sec. 2.22.7.1 "map Clause", p. 319, L14-16: > If a map clause with a present map-type-modifier is present in a map > clause, then the effect of the clause is ordered before all other > map clauses that do not have the present modifier. Compare to L10-11, which Clang does not appear to implement yet: > For a given construct, the effect of a map clause with the to, from, > or tofrom map-type is ordered before the effect of a map clause with > the alloc, release, or delete map-type. This patch also does not implement the `present` implicit-behavior for `defaultmap` or the `present` motion-modifier for `target update`. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D83061
2020-07-22 22:14:00 +08:00
Kind, Tok.isAnnotation() ? "" : P.getPreprocessor().getSpelling(Tok),
[OpenMP][OpenACC] Implement `ompx_hold` map type modifier extension in Clang (1/2) This patch implements Clang support for an original OpenMP extension we have developed to support OpenACC: the `ompx_hold` map type modifier. The next patch in this series, D106510, implements OpenMP runtime support. Consider the following example: ``` #pragma omp target data map(ompx_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 `ompx_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. (As usual, the standard OpenMP reference count for `x` must also reach zero before the data is unmapped.) Justification for inclusion in Clang and LLVM's OpenMP runtime: * The `ompx_hold` modifier supports OpenACC functionality (structured reference count) that cannot be achieved in standard OpenMP, as of 5.1. * The runtime implementation for `ompx_hold` (next patch) will thus be used by Flang's OpenACC support. * The Clang implementation for `ompx_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 `ompx_hold` is also used by the tests in the runtime implementation. That syntactic support makes the tests more readable than low-level runtime calls can. Moreover, upstream Flang and Clang do not yet support OpenACC syntax sufficiently for writing the tests. * More generally, the Clang implementation enables a clean separation of concerns between OpenACC and OpenMP development in LLVM. That is, LLVM's OpenMP developers can discuss, modify, and debug LLVM's extended OpenMP implementation and test suite without directly considering OpenACC's language and execution model, which can be handled by LLVM's OpenACC developers. * OpenMP users might find the `ompx_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. For example, it explains how the runtime must support two reference counts, as specified by OpenACC. Clang recognizes `ompx_hold` unless `-fno-openmp-extensions`, a new command-line option introduced by this patch, is specified. Reviewed By: ABataev, jdoerfert, protze.joachim, grokos Differential Revision: https://reviews.llvm.org/D106509
2021-09-01 03:17:07 +08:00
P.getLangOpts());
[OPENMP5.0]Add support for device_type clause in declare target construct. OpenMP 5.0 introduced new clause for declare target directive, device_type clause, which may accept values host, nohost, and any. Host means that the function must be emitted only for the host, nohost - only for the device, and any - for both, device and the host. llvm-svn: 369775
2019-08-24 00:11:14 +08:00
SourceLocation TypeLoc = Tok.getLocation();
if (Tok.isNot(tok::r_paren) && Tok.isNot(tok::comma) &&
Tok.isNot(tok::annot_pragma_openmp_end))
P.ConsumeAnyToken();
// Parse ')'.
SourceLocation RLoc = Tok.getLocation();
if (!T.consumeClose())
RLoc = T.getCloseLocation();
return SimpleClauseData(Type, Loc, LOpen, TypeLoc, RLoc);
}
[OpenMP] Overhaul `declare target` handling This patch fixes various issues with our prior `declare target` handling and extends it to support `omp begin declare target` as well. This started with PR49649 in mind, trying to provide a way for users to avoid the "ref" global use introduced for globals with internal linkage. From there it went down the rabbit hole, e.g., all variables, even `nohost` ones, were emitted into the device code so it was impossible to determine if "ref" was needed late in the game (based on the name only). To make it really useful, `begin declare target` was needed as it can carry the `device_type`. Not emitting variables eagerly had a ripple effect. Finally, the precedence of the (explicit) declare target list items needed to be taken into account, that meant we cannot just look for any declare target attribute to make a decision. This caused the handling of functions to require fixup as well. I tried to clean up things while I was at it, e.g., we should not "parse declarations and defintions" as part of OpenMP parsing, this will always break at some point. Instead, we keep track what region we are in and act on definitions and declarations instead, this is what we do for declare variant and other begin/end directives already. Highlights: - new diagnosis for restrictions specificed in the standard, - delayed emission of globals not mentioned in an explicit list of a declare target, - omission of `nohost` globals on the host and `host` globals on the device, - no explicit parsing of declarations in-between `omp [begin] declare variant` and the corresponding end anymore, regular parsing instead, - precedence for explicit mentions in `declare target` lists over implicit mentions in the declaration-definition-seq, and - `omp allocate` declarations will now replace an earlier emitted global, if necessary. --- Notes: The patch is larger than I hoped but it turns out that most changes do on their own lead to "inconsistent states", which seem less desirable overall. After working through this I feel the standard should remove the explicit declare target forms as the delayed emission is horrible. That said, while we delay things anyway, it seems to me we check too often for the current status even though that is often not sufficient to act upon. There seems to be a lot of duplication that can probably be trimmed down. Eagerly emitting some things seems pretty weak as an argument to keep so much logic around. --- Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D101030
2021-04-22 13:57:28 +08:00
void Parser::ParseOMPDeclareTargetClauses(
Sema::DeclareTargetContextInfo &DTCI) {
[OPENMP5.0]Add support for device_type clause in declare target construct. OpenMP 5.0 introduced new clause for declare target directive, device_type clause, which may accept values host, nohost, and any. Host means that the function must be emitted only for the host, nohost - only for the device, and any - for both, device and the host. llvm-svn: 369775
2019-08-24 00:11:14 +08:00
SourceLocation DeviceTypeLoc;
[OpenMP] Overhaul `declare target` handling This patch fixes various issues with our prior `declare target` handling and extends it to support `omp begin declare target` as well. This started with PR49649 in mind, trying to provide a way for users to avoid the "ref" global use introduced for globals with internal linkage. From there it went down the rabbit hole, e.g., all variables, even `nohost` ones, were emitted into the device code so it was impossible to determine if "ref" was needed late in the game (based on the name only). To make it really useful, `begin declare target` was needed as it can carry the `device_type`. Not emitting variables eagerly had a ripple effect. Finally, the precedence of the (explicit) declare target list items needed to be taken into account, that meant we cannot just look for any declare target attribute to make a decision. This caused the handling of functions to require fixup as well. I tried to clean up things while I was at it, e.g., we should not "parse declarations and defintions" as part of OpenMP parsing, this will always break at some point. Instead, we keep track what region we are in and act on definitions and declarations instead, this is what we do for declare variant and other begin/end directives already. Highlights: - new diagnosis for restrictions specificed in the standard, - delayed emission of globals not mentioned in an explicit list of a declare target, - omission of `nohost` globals on the host and `host` globals on the device, - no explicit parsing of declarations in-between `omp [begin] declare variant` and the corresponding end anymore, regular parsing instead, - precedence for explicit mentions in `declare target` lists over implicit mentions in the declaration-definition-seq, and - `omp allocate` declarations will now replace an earlier emitted global, if necessary. --- Notes: The patch is larger than I hoped but it turns out that most changes do on their own lead to "inconsistent states", which seem less desirable overall. After working through this I feel the standard should remove the explicit declare target forms as the delayed emission is horrible. That said, while we delay things anyway, it seems to me we check too often for the current status even though that is often not sufficient to act upon. There seems to be a lot of duplication that can probably be trimmed down. Eagerly emitting some things seems pretty weak as an argument to keep so much logic around. --- Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D101030
2021-04-22 13:57:28 +08:00
bool RequiresToOrLinkClause = false;
bool HasToOrLinkClause = false;
[OPENMP] Refactor code for parsing omp declare target directive and its clauses (NFC) This patch refactor the code for parsing omp declare target directive and its clauses. Patch by pjeeva01 (Jeeva P.) Differential Revision: https://reviews.llvm.org/D54708 llvm-svn: 347411
2018-11-22 04:15:57 +08:00
while (Tok.isNot(tok::annot_pragma_openmp_end)) {
OMPDeclareTargetDeclAttr::MapTypeTy MT = OMPDeclareTargetDeclAttr::MT_To;
[OpenMP] Overhaul `declare target` handling This patch fixes various issues with our prior `declare target` handling and extends it to support `omp begin declare target` as well. This started with PR49649 in mind, trying to provide a way for users to avoid the "ref" global use introduced for globals with internal linkage. From there it went down the rabbit hole, e.g., all variables, even `nohost` ones, were emitted into the device code so it was impossible to determine if "ref" was needed late in the game (based on the name only). To make it really useful, `begin declare target` was needed as it can carry the `device_type`. Not emitting variables eagerly had a ripple effect. Finally, the precedence of the (explicit) declare target list items needed to be taken into account, that meant we cannot just look for any declare target attribute to make a decision. This caused the handling of functions to require fixup as well. I tried to clean up things while I was at it, e.g., we should not "parse declarations and defintions" as part of OpenMP parsing, this will always break at some point. Instead, we keep track what region we are in and act on definitions and declarations instead, this is what we do for declare variant and other begin/end directives already. Highlights: - new diagnosis for restrictions specificed in the standard, - delayed emission of globals not mentioned in an explicit list of a declare target, - omission of `nohost` globals on the host and `host` globals on the device, - no explicit parsing of declarations in-between `omp [begin] declare variant` and the corresponding end anymore, regular parsing instead, - precedence for explicit mentions in `declare target` lists over implicit mentions in the declaration-definition-seq, and - `omp allocate` declarations will now replace an earlier emitted global, if necessary. --- Notes: The patch is larger than I hoped but it turns out that most changes do on their own lead to "inconsistent states", which seem less desirable overall. After working through this I feel the standard should remove the explicit declare target forms as the delayed emission is horrible. That said, while we delay things anyway, it seems to me we check too often for the current status even though that is often not sufficient to act upon. There seems to be a lot of duplication that can probably be trimmed down. Eagerly emitting some things seems pretty weak as an argument to keep so much logic around. --- Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D101030
2021-04-22 13:57:28 +08:00
bool HasIdentifier = Tok.is(tok::identifier);
if (HasIdentifier) {
// If we see any clause we need a to or link clause.
RequiresToOrLinkClause = true;
[OPENMP] Refactor code for parsing omp declare target directive and its clauses (NFC) This patch refactor the code for parsing omp declare target directive and its clauses. Patch by pjeeva01 (Jeeva P.) Differential Revision: https://reviews.llvm.org/D54708 llvm-svn: 347411
2018-11-22 04:15:57 +08:00
IdentifierInfo *II = Tok.getIdentifierInfo();
StringRef ClauseName = II->getName();
[OPENMP5.0]Add support for device_type clause in declare target construct. OpenMP 5.0 introduced new clause for declare target directive, device_type clause, which may accept values host, nohost, and any. Host means that the function must be emitted only for the host, nohost - only for the device, and any - for both, device and the host. llvm-svn: 369775
2019-08-24 00:11:14 +08:00
bool IsDeviceTypeClause =
getLangOpts().OpenMP >= 50 &&
getOpenMPClauseKind(ClauseName) == OMPC_device_type;
[OpenMP] Overhaul `declare target` handling This patch fixes various issues with our prior `declare target` handling and extends it to support `omp begin declare target` as well. This started with PR49649 in mind, trying to provide a way for users to avoid the "ref" global use introduced for globals with internal linkage. From there it went down the rabbit hole, e.g., all variables, even `nohost` ones, were emitted into the device code so it was impossible to determine if "ref" was needed late in the game (based on the name only). To make it really useful, `begin declare target` was needed as it can carry the `device_type`. Not emitting variables eagerly had a ripple effect. Finally, the precedence of the (explicit) declare target list items needed to be taken into account, that meant we cannot just look for any declare target attribute to make a decision. This caused the handling of functions to require fixup as well. I tried to clean up things while I was at it, e.g., we should not "parse declarations and defintions" as part of OpenMP parsing, this will always break at some point. Instead, we keep track what region we are in and act on definitions and declarations instead, this is what we do for declare variant and other begin/end directives already. Highlights: - new diagnosis for restrictions specificed in the standard, - delayed emission of globals not mentioned in an explicit list of a declare target, - omission of `nohost` globals on the host and `host` globals on the device, - no explicit parsing of declarations in-between `omp [begin] declare variant` and the corresponding end anymore, regular parsing instead, - precedence for explicit mentions in `declare target` lists over implicit mentions in the declaration-definition-seq, and - `omp allocate` declarations will now replace an earlier emitted global, if necessary. --- Notes: The patch is larger than I hoped but it turns out that most changes do on their own lead to "inconsistent states", which seem less desirable overall. After working through this I feel the standard should remove the explicit declare target forms as the delayed emission is horrible. That said, while we delay things anyway, it seems to me we check too often for the current status even though that is often not sufficient to act upon. There seems to be a lot of duplication that can probably be trimmed down. Eagerly emitting some things seems pretty weak as an argument to keep so much logic around. --- Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D101030
2021-04-22 13:57:28 +08:00
bool IsToOrLinkClause =
OMPDeclareTargetDeclAttr::ConvertStrToMapTypeTy(ClauseName, MT);
assert((!IsDeviceTypeClause || !IsToOrLinkClause) && "Cannot be both!");
if (!IsDeviceTypeClause && DTCI.Kind == OMPD_begin_declare_target) {
Diag(Tok, diag::err_omp_declare_target_unexpected_clause)
<< ClauseName << 0;
break;
}
if (!IsDeviceTypeClause && !IsToOrLinkClause) {
[OPENMP5.0]Add support for device_type clause in declare target construct. OpenMP 5.0 introduced new clause for declare target directive, device_type clause, which may accept values host, nohost, and any. Host means that the function must be emitted only for the host, nohost - only for the device, and any - for both, device and the host. llvm-svn: 369775
2019-08-24 00:11:14 +08:00
Diag(Tok, diag::err_omp_declare_target_unexpected_clause)
[OpenMP] Overhaul `declare target` handling This patch fixes various issues with our prior `declare target` handling and extends it to support `omp begin declare target` as well. This started with PR49649 in mind, trying to provide a way for users to avoid the "ref" global use introduced for globals with internal linkage. From there it went down the rabbit hole, e.g., all variables, even `nohost` ones, were emitted into the device code so it was impossible to determine if "ref" was needed late in the game (based on the name only). To make it really useful, `begin declare target` was needed as it can carry the `device_type`. Not emitting variables eagerly had a ripple effect. Finally, the precedence of the (explicit) declare target list items needed to be taken into account, that meant we cannot just look for any declare target attribute to make a decision. This caused the handling of functions to require fixup as well. I tried to clean up things while I was at it, e.g., we should not "parse declarations and defintions" as part of OpenMP parsing, this will always break at some point. Instead, we keep track what region we are in and act on definitions and declarations instead, this is what we do for declare variant and other begin/end directives already. Highlights: - new diagnosis for restrictions specificed in the standard, - delayed emission of globals not mentioned in an explicit list of a declare target, - omission of `nohost` globals on the host and `host` globals on the device, - no explicit parsing of declarations in-between `omp [begin] declare variant` and the corresponding end anymore, regular parsing instead, - precedence for explicit mentions in `declare target` lists over implicit mentions in the declaration-definition-seq, and - `omp allocate` declarations will now replace an earlier emitted global, if necessary. --- Notes: The patch is larger than I hoped but it turns out that most changes do on their own lead to "inconsistent states", which seem less desirable overall. After working through this I feel the standard should remove the explicit declare target forms as the delayed emission is horrible. That said, while we delay things anyway, it seems to me we check too often for the current status even though that is often not sufficient to act upon. There seems to be a lot of duplication that can probably be trimmed down. Eagerly emitting some things seems pretty weak as an argument to keep so much logic around. --- Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D101030
2021-04-22 13:57:28 +08:00
<< ClauseName << (getLangOpts().OpenMP >= 50 ? 2 : 1);
[OPENMP] Refactor code for parsing omp declare target directive and its clauses (NFC) This patch refactor the code for parsing omp declare target directive and its clauses. Patch by pjeeva01 (Jeeva P.) Differential Revision: https://reviews.llvm.org/D54708 llvm-svn: 347411
2018-11-22 04:15:57 +08:00
break;
}
[OpenMP] Overhaul `declare target` handling This patch fixes various issues with our prior `declare target` handling and extends it to support `omp begin declare target` as well. This started with PR49649 in mind, trying to provide a way for users to avoid the "ref" global use introduced for globals with internal linkage. From there it went down the rabbit hole, e.g., all variables, even `nohost` ones, were emitted into the device code so it was impossible to determine if "ref" was needed late in the game (based on the name only). To make it really useful, `begin declare target` was needed as it can carry the `device_type`. Not emitting variables eagerly had a ripple effect. Finally, the precedence of the (explicit) declare target list items needed to be taken into account, that meant we cannot just look for any declare target attribute to make a decision. This caused the handling of functions to require fixup as well. I tried to clean up things while I was at it, e.g., we should not "parse declarations and defintions" as part of OpenMP parsing, this will always break at some point. Instead, we keep track what region we are in and act on definitions and declarations instead, this is what we do for declare variant and other begin/end directives already. Highlights: - new diagnosis for restrictions specificed in the standard, - delayed emission of globals not mentioned in an explicit list of a declare target, - omission of `nohost` globals on the host and `host` globals on the device, - no explicit parsing of declarations in-between `omp [begin] declare variant` and the corresponding end anymore, regular parsing instead, - precedence for explicit mentions in `declare target` lists over implicit mentions in the declaration-definition-seq, and - `omp allocate` declarations will now replace an earlier emitted global, if necessary. --- Notes: The patch is larger than I hoped but it turns out that most changes do on their own lead to "inconsistent states", which seem less desirable overall. After working through this I feel the standard should remove the explicit declare target forms as the delayed emission is horrible. That said, while we delay things anyway, it seems to me we check too often for the current status even though that is often not sufficient to act upon. There seems to be a lot of duplication that can probably be trimmed down. Eagerly emitting some things seems pretty weak as an argument to keep so much logic around. --- Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D101030
2021-04-22 13:57:28 +08:00
if (IsToOrLinkClause)
HasToOrLinkClause = true;
[OPENMP5.0]Add support for device_type clause in declare target construct. OpenMP 5.0 introduced new clause for declare target directive, device_type clause, which may accept values host, nohost, and any. Host means that the function must be emitted only for the host, nohost - only for the device, and any - for both, device and the host. llvm-svn: 369775
2019-08-24 00:11:14 +08:00
// Parse 'device_type' clause and go to next clause if any.
if (IsDeviceTypeClause) {
Optional<SimpleClauseData> DevTypeData =
parseOpenMPSimpleClause(*this, OMPC_device_type);
if (DevTypeData.hasValue()) {
if (DeviceTypeLoc.isValid()) {
// We already saw another device_type clause, diagnose it.
Diag(DevTypeData.getValue().Loc,
diag::warn_omp_more_one_device_type_clause);
[OpenMP] Overhaul `declare target` handling This patch fixes various issues with our prior `declare target` handling and extends it to support `omp begin declare target` as well. This started with PR49649 in mind, trying to provide a way for users to avoid the "ref" global use introduced for globals with internal linkage. From there it went down the rabbit hole, e.g., all variables, even `nohost` ones, were emitted into the device code so it was impossible to determine if "ref" was needed late in the game (based on the name only). To make it really useful, `begin declare target` was needed as it can carry the `device_type`. Not emitting variables eagerly had a ripple effect. Finally, the precedence of the (explicit) declare target list items needed to be taken into account, that meant we cannot just look for any declare target attribute to make a decision. This caused the handling of functions to require fixup as well. I tried to clean up things while I was at it, e.g., we should not "parse declarations and defintions" as part of OpenMP parsing, this will always break at some point. Instead, we keep track what region we are in and act on definitions and declarations instead, this is what we do for declare variant and other begin/end directives already. Highlights: - new diagnosis for restrictions specificed in the standard, - delayed emission of globals not mentioned in an explicit list of a declare target, - omission of `nohost` globals on the host and `host` globals on the device, - no explicit parsing of declarations in-between `omp [begin] declare variant` and the corresponding end anymore, regular parsing instead, - precedence for explicit mentions in `declare target` lists over implicit mentions in the declaration-definition-seq, and - `omp allocate` declarations will now replace an earlier emitted global, if necessary. --- Notes: The patch is larger than I hoped but it turns out that most changes do on their own lead to "inconsistent states", which seem less desirable overall. After working through this I feel the standard should remove the explicit declare target forms as the delayed emission is horrible. That said, while we delay things anyway, it seems to me we check too often for the current status even though that is often not sufficient to act upon. There seems to be a lot of duplication that can probably be trimmed down. Eagerly emitting some things seems pretty weak as an argument to keep so much logic around. --- Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D101030
2021-04-22 13:57:28 +08:00
break;
[OPENMP5.0]Add support for device_type clause in declare target construct. OpenMP 5.0 introduced new clause for declare target directive, device_type clause, which may accept values host, nohost, and any. Host means that the function must be emitted only for the host, nohost - only for the device, and any - for both, device and the host. llvm-svn: 369775
2019-08-24 00:11:14 +08:00
}
[OpenMP][NFC] Clang format ParseOpenMP ParseOpenMP.cpp was pretty much clang-formatted except a few minor locations. Let's make it a clang formatted file. Reviewed By: JonChesterfield Differential Revision: https://reviews.llvm.org/D90440
2020-10-30 07:44:28 +08:00
switch (static_cast<OpenMPDeviceType>(DevTypeData.getValue().Type)) {
[OPENMP5.0]Add support for device_type clause in declare target construct. OpenMP 5.0 introduced new clause for declare target directive, device_type clause, which may accept values host, nohost, and any. Host means that the function must be emitted only for the host, nohost - only for the device, and any - for both, device and the host. llvm-svn: 369775
2019-08-24 00:11:14 +08:00
case OMPC_DEVICE_TYPE_any:
[OpenMP] Overhaul `declare target` handling This patch fixes various issues with our prior `declare target` handling and extends it to support `omp begin declare target` as well. This started with PR49649 in mind, trying to provide a way for users to avoid the "ref" global use introduced for globals with internal linkage. From there it went down the rabbit hole, e.g., all variables, even `nohost` ones, were emitted into the device code so it was impossible to determine if "ref" was needed late in the game (based on the name only). To make it really useful, `begin declare target` was needed as it can carry the `device_type`. Not emitting variables eagerly had a ripple effect. Finally, the precedence of the (explicit) declare target list items needed to be taken into account, that meant we cannot just look for any declare target attribute to make a decision. This caused the handling of functions to require fixup as well. I tried to clean up things while I was at it, e.g., we should not "parse declarations and defintions" as part of OpenMP parsing, this will always break at some point. Instead, we keep track what region we are in and act on definitions and declarations instead, this is what we do for declare variant and other begin/end directives already. Highlights: - new diagnosis for restrictions specificed in the standard, - delayed emission of globals not mentioned in an explicit list of a declare target, - omission of `nohost` globals on the host and `host` globals on the device, - no explicit parsing of declarations in-between `omp [begin] declare variant` and the corresponding end anymore, regular parsing instead, - precedence for explicit mentions in `declare target` lists over implicit mentions in the declaration-definition-seq, and - `omp allocate` declarations will now replace an earlier emitted global, if necessary. --- Notes: The patch is larger than I hoped but it turns out that most changes do on their own lead to "inconsistent states", which seem less desirable overall. After working through this I feel the standard should remove the explicit declare target forms as the delayed emission is horrible. That said, while we delay things anyway, it seems to me we check too often for the current status even though that is often not sufficient to act upon. There seems to be a lot of duplication that can probably be trimmed down. Eagerly emitting some things seems pretty weak as an argument to keep so much logic around. --- Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D101030
2021-04-22 13:57:28 +08:00
DTCI.DT = OMPDeclareTargetDeclAttr::DT_Any;
[OPENMP5.0]Add support for device_type clause in declare target construct. OpenMP 5.0 introduced new clause for declare target directive, device_type clause, which may accept values host, nohost, and any. Host means that the function must be emitted only for the host, nohost - only for the device, and any - for both, device and the host. llvm-svn: 369775
2019-08-24 00:11:14 +08:00
break;
case OMPC_DEVICE_TYPE_host:
[OpenMP] Overhaul `declare target` handling This patch fixes various issues with our prior `declare target` handling and extends it to support `omp begin declare target` as well. This started with PR49649 in mind, trying to provide a way for users to avoid the "ref" global use introduced for globals with internal linkage. From there it went down the rabbit hole, e.g., all variables, even `nohost` ones, were emitted into the device code so it was impossible to determine if "ref" was needed late in the game (based on the name only). To make it really useful, `begin declare target` was needed as it can carry the `device_type`. Not emitting variables eagerly had a ripple effect. Finally, the precedence of the (explicit) declare target list items needed to be taken into account, that meant we cannot just look for any declare target attribute to make a decision. This caused the handling of functions to require fixup as well. I tried to clean up things while I was at it, e.g., we should not "parse declarations and defintions" as part of OpenMP parsing, this will always break at some point. Instead, we keep track what region we are in and act on definitions and declarations instead, this is what we do for declare variant and other begin/end directives already. Highlights: - new diagnosis for restrictions specificed in the standard, - delayed emission of globals not mentioned in an explicit list of a declare target, - omission of `nohost` globals on the host and `host` globals on the device, - no explicit parsing of declarations in-between `omp [begin] declare variant` and the corresponding end anymore, regular parsing instead, - precedence for explicit mentions in `declare target` lists over implicit mentions in the declaration-definition-seq, and - `omp allocate` declarations will now replace an earlier emitted global, if necessary. --- Notes: The patch is larger than I hoped but it turns out that most changes do on their own lead to "inconsistent states", which seem less desirable overall. After working through this I feel the standard should remove the explicit declare target forms as the delayed emission is horrible. That said, while we delay things anyway, it seems to me we check too often for the current status even though that is often not sufficient to act upon. There seems to be a lot of duplication that can probably be trimmed down. Eagerly emitting some things seems pretty weak as an argument to keep so much logic around. --- Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D101030
2021-04-22 13:57:28 +08:00
DTCI.DT = OMPDeclareTargetDeclAttr::DT_Host;
[OPENMP5.0]Add support for device_type clause in declare target construct. OpenMP 5.0 introduced new clause for declare target directive, device_type clause, which may accept values host, nohost, and any. Host means that the function must be emitted only for the host, nohost - only for the device, and any - for both, device and the host. llvm-svn: 369775
2019-08-24 00:11:14 +08:00
break;
case OMPC_DEVICE_TYPE_nohost:
[OpenMP] Overhaul `declare target` handling This patch fixes various issues with our prior `declare target` handling and extends it to support `omp begin declare target` as well. This started with PR49649 in mind, trying to provide a way for users to avoid the "ref" global use introduced for globals with internal linkage. From there it went down the rabbit hole, e.g., all variables, even `nohost` ones, were emitted into the device code so it was impossible to determine if "ref" was needed late in the game (based on the name only). To make it really useful, `begin declare target` was needed as it can carry the `device_type`. Not emitting variables eagerly had a ripple effect. Finally, the precedence of the (explicit) declare target list items needed to be taken into account, that meant we cannot just look for any declare target attribute to make a decision. This caused the handling of functions to require fixup as well. I tried to clean up things while I was at it, e.g., we should not "parse declarations and defintions" as part of OpenMP parsing, this will always break at some point. Instead, we keep track what region we are in and act on definitions and declarations instead, this is what we do for declare variant and other begin/end directives already. Highlights: - new diagnosis for restrictions specificed in the standard, - delayed emission of globals not mentioned in an explicit list of a declare target, - omission of `nohost` globals on the host and `host` globals on the device, - no explicit parsing of declarations in-between `omp [begin] declare variant` and the corresponding end anymore, regular parsing instead, - precedence for explicit mentions in `declare target` lists over implicit mentions in the declaration-definition-seq, and - `omp allocate` declarations will now replace an earlier emitted global, if necessary. --- Notes: The patch is larger than I hoped but it turns out that most changes do on their own lead to "inconsistent states", which seem less desirable overall. After working through this I feel the standard should remove the explicit declare target forms as the delayed emission is horrible. That said, while we delay things anyway, it seems to me we check too often for the current status even though that is often not sufficient to act upon. There seems to be a lot of duplication that can probably be trimmed down. Eagerly emitting some things seems pretty weak as an argument to keep so much logic around. --- Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D101030
2021-04-22 13:57:28 +08:00
DTCI.DT = OMPDeclareTargetDeclAttr::DT_NoHost;
[OPENMP5.0]Add support for device_type clause in declare target construct. OpenMP 5.0 introduced new clause for declare target directive, device_type clause, which may accept values host, nohost, and any. Host means that the function must be emitted only for the host, nohost - only for the device, and any - for both, device and the host. llvm-svn: 369775
2019-08-24 00:11:14 +08:00
break;
case OMPC_DEVICE_TYPE_unknown:
llvm_unreachable("Unexpected device_type");
}
DeviceTypeLoc = DevTypeData.getValue().Loc;
}
continue;
}
[OPENMP] Refactor code for parsing omp declare target directive and its clauses (NFC) This patch refactor the code for parsing omp declare target directive and its clauses. Patch by pjeeva01 (Jeeva P.) Differential Revision: https://reviews.llvm.org/D54708 llvm-svn: 347411
2018-11-22 04:15:57 +08:00
ConsumeToken();
}
[OpenMP] Overhaul `declare target` handling This patch fixes various issues with our prior `declare target` handling and extends it to support `omp begin declare target` as well. This started with PR49649 in mind, trying to provide a way for users to avoid the "ref" global use introduced for globals with internal linkage. From there it went down the rabbit hole, e.g., all variables, even `nohost` ones, were emitted into the device code so it was impossible to determine if "ref" was needed late in the game (based on the name only). To make it really useful, `begin declare target` was needed as it can carry the `device_type`. Not emitting variables eagerly had a ripple effect. Finally, the precedence of the (explicit) declare target list items needed to be taken into account, that meant we cannot just look for any declare target attribute to make a decision. This caused the handling of functions to require fixup as well. I tried to clean up things while I was at it, e.g., we should not "parse declarations and defintions" as part of OpenMP parsing, this will always break at some point. Instead, we keep track what region we are in and act on definitions and declarations instead, this is what we do for declare variant and other begin/end directives already. Highlights: - new diagnosis for restrictions specificed in the standard, - delayed emission of globals not mentioned in an explicit list of a declare target, - omission of `nohost` globals on the host and `host` globals on the device, - no explicit parsing of declarations in-between `omp [begin] declare variant` and the corresponding end anymore, regular parsing instead, - precedence for explicit mentions in `declare target` lists over implicit mentions in the declaration-definition-seq, and - `omp allocate` declarations will now replace an earlier emitted global, if necessary. --- Notes: The patch is larger than I hoped but it turns out that most changes do on their own lead to "inconsistent states", which seem less desirable overall. After working through this I feel the standard should remove the explicit declare target forms as the delayed emission is horrible. That said, while we delay things anyway, it seems to me we check too often for the current status even though that is often not sufficient to act upon. There seems to be a lot of duplication that can probably be trimmed down. Eagerly emitting some things seems pretty weak as an argument to keep so much logic around. --- Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D101030
2021-04-22 13:57:28 +08:00
if (DTCI.Kind == OMPD_declare_target || HasIdentifier) {
auto &&Callback = [this, MT, &DTCI](CXXScopeSpec &SS,
DeclarationNameInfo NameInfo) {
NamedDecl *ND =
Actions.lookupOpenMPDeclareTargetName(getCurScope(), SS, NameInfo);
if (!ND)
return;
Sema::DeclareTargetContextInfo::MapInfo MI{MT, NameInfo.getLoc()};
bool FirstMapping = DTCI.ExplicitlyMapped.try_emplace(ND, MI).second;
if (!FirstMapping)
Diag(NameInfo.getLoc(), diag::err_omp_declare_target_multiple)
<< NameInfo.getName();
};
if (ParseOpenMPSimpleVarList(OMPD_declare_target, Callback,
/*AllowScopeSpecifier=*/true))
break;
}
if (Tok.is(tok::l_paren)) {
Diag(Tok,
diag::err_omp_begin_declare_target_unexpected_implicit_to_clause);
break;
}
if (!HasIdentifier && Tok.isNot(tok::annot_pragma_openmp_end)) {
Diag(Tok,
diag::err_omp_declare_target_unexpected_clause_after_implicit_to);
[OPENMP] Refactor code for parsing omp declare target directive and its clauses (NFC) This patch refactor the code for parsing omp declare target directive and its clauses. Patch by pjeeva01 (Jeeva P.) Differential Revision: https://reviews.llvm.org/D54708 llvm-svn: 347411
2018-11-22 04:15:57 +08:00
break;
[OpenMP] Overhaul `declare target` handling This patch fixes various issues with our prior `declare target` handling and extends it to support `omp begin declare target` as well. This started with PR49649 in mind, trying to provide a way for users to avoid the "ref" global use introduced for globals with internal linkage. From there it went down the rabbit hole, e.g., all variables, even `nohost` ones, were emitted into the device code so it was impossible to determine if "ref" was needed late in the game (based on the name only). To make it really useful, `begin declare target` was needed as it can carry the `device_type`. Not emitting variables eagerly had a ripple effect. Finally, the precedence of the (explicit) declare target list items needed to be taken into account, that meant we cannot just look for any declare target attribute to make a decision. This caused the handling of functions to require fixup as well. I tried to clean up things while I was at it, e.g., we should not "parse declarations and defintions" as part of OpenMP parsing, this will always break at some point. Instead, we keep track what region we are in and act on definitions and declarations instead, this is what we do for declare variant and other begin/end directives already. Highlights: - new diagnosis for restrictions specificed in the standard, - delayed emission of globals not mentioned in an explicit list of a declare target, - omission of `nohost` globals on the host and `host` globals on the device, - no explicit parsing of declarations in-between `omp [begin] declare variant` and the corresponding end anymore, regular parsing instead, - precedence for explicit mentions in `declare target` lists over implicit mentions in the declaration-definition-seq, and - `omp allocate` declarations will now replace an earlier emitted global, if necessary. --- Notes: The patch is larger than I hoped but it turns out that most changes do on their own lead to "inconsistent states", which seem less desirable overall. After working through this I feel the standard should remove the explicit declare target forms as the delayed emission is horrible. That said, while we delay things anyway, it seems to me we check too often for the current status even though that is often not sufficient to act upon. There seems to be a lot of duplication that can probably be trimmed down. Eagerly emitting some things seems pretty weak as an argument to keep so much logic around. --- Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D101030
2021-04-22 13:57:28 +08:00
}
[OPENMP] Refactor code for parsing omp declare target directive and its clauses (NFC) This patch refactor the code for parsing omp declare target directive and its clauses. Patch by pjeeva01 (Jeeva P.) Differential Revision: https://reviews.llvm.org/D54708 llvm-svn: 347411
2018-11-22 04:15:57 +08:00
// Consume optional ','.
if (Tok.is(tok::comma))
ConsumeToken();
}
[OpenMP] Overhaul `declare target` handling This patch fixes various issues with our prior `declare target` handling and extends it to support `omp begin declare target` as well. This started with PR49649 in mind, trying to provide a way for users to avoid the "ref" global use introduced for globals with internal linkage. From there it went down the rabbit hole, e.g., all variables, even `nohost` ones, were emitted into the device code so it was impossible to determine if "ref" was needed late in the game (based on the name only). To make it really useful, `begin declare target` was needed as it can carry the `device_type`. Not emitting variables eagerly had a ripple effect. Finally, the precedence of the (explicit) declare target list items needed to be taken into account, that meant we cannot just look for any declare target attribute to make a decision. This caused the handling of functions to require fixup as well. I tried to clean up things while I was at it, e.g., we should not "parse declarations and defintions" as part of OpenMP parsing, this will always break at some point. Instead, we keep track what region we are in and act on definitions and declarations instead, this is what we do for declare variant and other begin/end directives already. Highlights: - new diagnosis for restrictions specificed in the standard, - delayed emission of globals not mentioned in an explicit list of a declare target, - omission of `nohost` globals on the host and `host` globals on the device, - no explicit parsing of declarations in-between `omp [begin] declare variant` and the corresponding end anymore, regular parsing instead, - precedence for explicit mentions in `declare target` lists over implicit mentions in the declaration-definition-seq, and - `omp allocate` declarations will now replace an earlier emitted global, if necessary. --- Notes: The patch is larger than I hoped but it turns out that most changes do on their own lead to "inconsistent states", which seem less desirable overall. After working through this I feel the standard should remove the explicit declare target forms as the delayed emission is horrible. That said, while we delay things anyway, it seems to me we check too often for the current status even though that is often not sufficient to act upon. There seems to be a lot of duplication that can probably be trimmed down. Eagerly emitting some things seems pretty weak as an argument to keep so much logic around. --- Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D101030
2021-04-22 13:57:28 +08:00
// For declare target require at least 'to' or 'link' to be present.
if (DTCI.Kind == OMPD_declare_target && RequiresToOrLinkClause &&
!HasToOrLinkClause)
Diag(DTCI.Loc, diag::err_omp_declare_target_missing_to_or_link_clause);
[OPENMP] Refactor code for parsing omp declare target directive and its clauses (NFC) This patch refactor the code for parsing omp declare target directive and its clauses. Patch by pjeeva01 (Jeeva P.) Differential Revision: https://reviews.llvm.org/D54708 llvm-svn: 347411
2018-11-22 04:15:57 +08:00
SkipUntil(tok::annot_pragma_openmp_end, StopBeforeMatch);
}
[OpenMP][NFC] Outline common functionality (skipUntilPragmaOpenMPEnd) The same code was repeated multiple times, we put it in a function now.
2020-02-22 03:48:56 +08:00
void Parser::skipUntilPragmaOpenMPEnd(OpenMPDirectiveKind DKind) {
// The last seen token is annot_pragma_openmp_end - need to check for
// extra tokens.
if (Tok.is(tok::annot_pragma_openmp_end))
return;
Diag(Tok, diag::warn_omp_extra_tokens_at_eol)
<< getOpenMPDirectiveName(DKind);
while (Tok.isNot(tok::annot_pragma_openmp_end))
ConsumeAnyToken();
}
[OpenMP] `omp begin/end declare variant` - part 1, parsing This is the first part extracted from D71179 and cleaned up. This patch provides parsing support for `omp begin/end declare variant`, as defined in OpenMP technical report 8 (TR8) [0]. A major purpose of this patch is to provide proper math.h/cmath support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D74941
2020-02-21 09:50:47 +08:00
void Parser::parseOMPEndDirective(OpenMPDirectiveKind BeginKind,
OpenMPDirectiveKind ExpectedKind,
OpenMPDirectiveKind FoundKind,
SourceLocation BeginLoc,
SourceLocation FoundLoc,
bool SkipUntilOpenMPEnd) {
int DiagSelection = ExpectedKind == OMPD_end_declare_target ? 0 : 1;
if (FoundKind == ExpectedKind) {
ConsumeAnyToken();
skipUntilPragmaOpenMPEnd(ExpectedKind);
[OPENMP] Refactor code for parsing omp declare target directive and its clauses (NFC) This patch refactor the code for parsing omp declare target directive and its clauses. Patch by pjeeva01 (Jeeva P.) Differential Revision: https://reviews.llvm.org/D54708 llvm-svn: 347411
2018-11-22 04:15:57 +08:00
return;
}
[OpenMP] `omp begin/end declare variant` - part 1, parsing This is the first part extracted from D71179 and cleaned up. This patch provides parsing support for `omp begin/end declare variant`, as defined in OpenMP technical report 8 (TR8) [0]. A major purpose of this patch is to provide proper math.h/cmath support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D74941
2020-02-21 09:50:47 +08:00
Diag(FoundLoc, diag::err_expected_end_declare_target_or_variant)
<< DiagSelection;
Diag(BeginLoc, diag::note_matching)
<< ("'#pragma omp " + getOpenMPDirectiveName(BeginKind) + "'").str();
if (SkipUntilOpenMPEnd)
SkipUntil(tok::annot_pragma_openmp_end, StopBeforeMatch);
}
[OpenMP] Overhaul `declare target` handling This patch fixes various issues with our prior `declare target` handling and extends it to support `omp begin declare target` as well. This started with PR49649 in mind, trying to provide a way for users to avoid the "ref" global use introduced for globals with internal linkage. From there it went down the rabbit hole, e.g., all variables, even `nohost` ones, were emitted into the device code so it was impossible to determine if "ref" was needed late in the game (based on the name only). To make it really useful, `begin declare target` was needed as it can carry the `device_type`. Not emitting variables eagerly had a ripple effect. Finally, the precedence of the (explicit) declare target list items needed to be taken into account, that meant we cannot just look for any declare target attribute to make a decision. This caused the handling of functions to require fixup as well. I tried to clean up things while I was at it, e.g., we should not "parse declarations and defintions" as part of OpenMP parsing, this will always break at some point. Instead, we keep track what region we are in and act on definitions and declarations instead, this is what we do for declare variant and other begin/end directives already. Highlights: - new diagnosis for restrictions specificed in the standard, - delayed emission of globals not mentioned in an explicit list of a declare target, - omission of `nohost` globals on the host and `host` globals on the device, - no explicit parsing of declarations in-between `omp [begin] declare variant` and the corresponding end anymore, regular parsing instead, - precedence for explicit mentions in `declare target` lists over implicit mentions in the declaration-definition-seq, and - `omp allocate` declarations will now replace an earlier emitted global, if necessary. --- Notes: The patch is larger than I hoped but it turns out that most changes do on their own lead to "inconsistent states", which seem less desirable overall. After working through this I feel the standard should remove the explicit declare target forms as the delayed emission is horrible. That said, while we delay things anyway, it seems to me we check too often for the current status even though that is often not sufficient to act upon. There seems to be a lot of duplication that can probably be trimmed down. Eagerly emitting some things seems pretty weak as an argument to keep so much logic around. --- Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D101030
2021-04-22 13:57:28 +08:00
void Parser::ParseOMPEndDeclareTargetDirective(OpenMPDirectiveKind BeginDKind,
OpenMPDirectiveKind EndDKind,
[OpenMP] `omp begin/end declare variant` - part 1, parsing This is the first part extracted from D71179 and cleaned up. This patch provides parsing support for `omp begin/end declare variant`, as defined in OpenMP technical report 8 (TR8) [0]. A major purpose of this patch is to provide proper math.h/cmath support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D74941
2020-02-21 09:50:47 +08:00
SourceLocation DKLoc) {
[OpenMP] Overhaul `declare target` handling This patch fixes various issues with our prior `declare target` handling and extends it to support `omp begin declare target` as well. This started with PR49649 in mind, trying to provide a way for users to avoid the "ref" global use introduced for globals with internal linkage. From there it went down the rabbit hole, e.g., all variables, even `nohost` ones, were emitted into the device code so it was impossible to determine if "ref" was needed late in the game (based on the name only). To make it really useful, `begin declare target` was needed as it can carry the `device_type`. Not emitting variables eagerly had a ripple effect. Finally, the precedence of the (explicit) declare target list items needed to be taken into account, that meant we cannot just look for any declare target attribute to make a decision. This caused the handling of functions to require fixup as well. I tried to clean up things while I was at it, e.g., we should not "parse declarations and defintions" as part of OpenMP parsing, this will always break at some point. Instead, we keep track what region we are in and act on definitions and declarations instead, this is what we do for declare variant and other begin/end directives already. Highlights: - new diagnosis for restrictions specificed in the standard, - delayed emission of globals not mentioned in an explicit list of a declare target, - omission of `nohost` globals on the host and `host` globals on the device, - no explicit parsing of declarations in-between `omp [begin] declare variant` and the corresponding end anymore, regular parsing instead, - precedence for explicit mentions in `declare target` lists over implicit mentions in the declaration-definition-seq, and - `omp allocate` declarations will now replace an earlier emitted global, if necessary. --- Notes: The patch is larger than I hoped but it turns out that most changes do on their own lead to "inconsistent states", which seem less desirable overall. After working through this I feel the standard should remove the explicit declare target forms as the delayed emission is horrible. That said, while we delay things anyway, it seems to me we check too often for the current status even though that is often not sufficient to act upon. There seems to be a lot of duplication that can probably be trimmed down. Eagerly emitting some things seems pretty weak as an argument to keep so much logic around. --- Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D101030
2021-04-22 13:57:28 +08:00
parseOMPEndDirective(BeginDKind, OMPD_end_declare_target, EndDKind, DKLoc,
Tok.getLocation(),
[OpenMP] `omp begin/end declare variant` - part 1, parsing This is the first part extracted from D71179 and cleaned up. This patch provides parsing support for `omp begin/end declare variant`, as defined in OpenMP technical report 8 (TR8) [0]. A major purpose of this patch is to provide proper math.h/cmath support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D74941
2020-02-21 09:50:47 +08:00
/* SkipUntilOpenMPEnd */ false);
[OPENMP] Refactor code for parsing omp declare target directive and its clauses (NFC) This patch refactor the code for parsing omp declare target directive and its clauses. Patch by pjeeva01 (Jeeva P.) Differential Revision: https://reviews.llvm.org/D54708 llvm-svn: 347411
2018-11-22 04:15:57 +08:00
// Skip the last annot_pragma_openmp_end.
[OpenMP] `omp begin/end declare variant` - part 1, parsing This is the first part extracted from D71179 and cleaned up. This patch provides parsing support for `omp begin/end declare variant`, as defined in OpenMP technical report 8 (TR8) [0]. A major purpose of this patch is to provide proper math.h/cmath support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D74941
2020-02-21 09:50:47 +08:00
if (Tok.is(tok::annot_pragma_openmp_end))
ConsumeAnnotationToken();
[OPENMP] Refactor code for parsing omp declare target directive and its clauses (NFC) This patch refactor the code for parsing omp declare target directive and its clauses. Patch by pjeeva01 (Jeeva P.) Differential Revision: https://reviews.llvm.org/D54708 llvm-svn: 347411
2018-11-22 04:15:57 +08:00
}
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Parsing of declarative OpenMP directives.
OpenMP threadprivate with qualified names. llvm-svn: 181683
2013-05-13 12:18:18 +08:00
///
/// threadprivate-directive:
/// annot_pragma_openmp 'threadprivate' simple-variable-list
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
/// annot_pragma_openmp_end
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 14:34:35 +08:00
///
[OPENMP 5.0]Add initial support for 'allocate' directive. Added parsing/sema analysis/serialization/deserialization support for 'allocate' directive. llvm-svn: 355614
2019-03-08 01:54:44 +08:00
/// allocate-directive:
[OPENMP 5.0]Initial support for 'allocator' clause. Added parsing/sema analysis/serialization/deserialization for the 'allocator' clause of the 'allocate' directive. llvm-svn: 355952
2019-03-13 02:52:33 +08:00
/// annot_pragma_openmp 'allocate' simple-variable-list [<clause>]
[OPENMP 5.0]Add initial support for 'allocate' directive. Added parsing/sema analysis/serialization/deserialization support for 'allocate' directive. llvm-svn: 355614
2019-03-08 01:54:44 +08:00
/// annot_pragma_openmp_end
///
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
/// declare-reduction-directive:
/// annot_pragma_openmp 'declare' 'reduction' [...]
/// annot_pragma_openmp_end
///
[OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive. This patch implements parsing and sema for "omp declare mapper" directive. User defined mapper, i.e., declare mapper directive, is a new feature in OpenMP 5.0. It is introduced to extend existing map clauses for the purpose of simplifying the copy of complex data structures between host and device (i.e., deep copy). An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(struct S s) map(s, s.d[0:s.len]) // Memory region that d points to is also mapped using this mapper. Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D56326 llvm-svn: 352906
2019-02-02 04:25:04 +08:00
/// declare-mapper-directive:
/// annot_pragma_openmp 'declare' 'mapper' '(' [<mapper-identifer> ':']
/// <type> <var> ')' [<clause>[[,] <clause>] ... ]
/// annot_pragma_openmp_end
///
[OPENMP 4.0] Initial support for '#pragma omp declare simd' directive. Initial parsing/sema/serialization/deserialization support for '#pragma omp declare simd' directive. The 'declare simd' construct can be applied to a function to enable the creation of one or more versions that can process multiple arguments using SIMD instructions from a single invocation from a SIMD loop. If the function has any declarations, then the declare simd construct for any declaration that has one must be equivalent to the one specified for the definition. Otherwise, the result is unspecified. This pragma can be applied many times to the same declaration. Internally this pragma is represented as an attribute. But we need special processing for this pragma because it must be used before function declaration, this directive is applied to. Differential Revision: http://reviews.llvm.org/D10599 llvm-svn: 264853
2016-03-30 18:43:55 +08:00
/// declare-simd-directive:
/// annot_pragma_openmp 'declare simd' {<clause> [,]}
/// annot_pragma_openmp_end
/// <function declaration/definition>
///
[OPENMP] Add support for OMP5 requires directive + unified_address clause Add support for OMP5.0 requires directive and unified_address clause. Patches to follow will include support for additional clauses. Differential Revision: https://reviews.llvm.org/D52359 llvm-svn: 343063
2018-09-26 12:28:39 +08:00
/// requires directive:
/// annot_pragma_openmp 'requires' <clause> [[[,] <clause>] ... ]
/// annot_pragma_openmp_end
///
[OpenMP] Add initial support for `omp [begin/end] assumes` The `assumes` directive is an OpenMP 5.1 feature that allows the user to provide assumptions to the optimizer. Assumptions can refer to directives (`absent` and `contains` clauses), expressions (`holds` clause), or generic properties (`no_openmp_routines`, `ext_ABCD`, ...). The `assumes` spelling is used for assumptions in the global scope while `assume` is used for executable contexts with an associated structured block. This patch only implements the global spellings. While clauses with arguments are "accepted" by the parser, they will simply be ignored for now. The implementation lowers the assumptions directly to the `AssumptionAttr`. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D91980
2020-11-24 01:48:59 +08:00
/// assumes directive:
/// annot_pragma_openmp 'assumes' <clause> [[[,] <clause>] ... ]
/// annot_pragma_openmp_end
/// or
/// annot_pragma_openmp 'begin assumes' <clause> [[[,] <clause>] ... ]
/// annot_pragma_openmp 'end assumes'
/// annot_pragma_openmp_end
///
[OPENMP 4.0] Initial support for '#pragma omp declare simd' directive. Initial parsing/sema/serialization/deserialization support for '#pragma omp declare simd' directive. The 'declare simd' construct can be applied to a function to enable the creation of one or more versions that can process multiple arguments using SIMD instructions from a single invocation from a SIMD loop. If the function has any declarations, then the declare simd construct for any declaration that has one must be equivalent to the one specified for the definition. Otherwise, the result is unspecified. This pragma can be applied many times to the same declaration. Internally this pragma is represented as an attribute. But we need special processing for this pragma because it must be used before function declaration, this directive is applied to. Differential Revision: http://reviews.llvm.org/D10599 llvm-svn: 264853
2016-03-30 18:43:55 +08:00
Parser::DeclGroupPtrTy Parser::ParseOpenMPDeclarativeDirectiveWithExtDecl(
[OPENMP]Allow using of members in standalone declaration pragmas. If standalone OpenMP declaration pragma, like declare mapper or declare reduction, is declared in the class context, it may reference a member (data or function) in its internal expressions/statements. So, the parsing of such pragmas must be dalayed just like the parsing of the member initializers/definitions before the completion of the class declaration.
2020-01-08 02:39:18 +08:00
AccessSpecifier &AS, ParsedAttributesWithRange &Attrs, bool Delayed,
[OPENMP 4.0] Initial support for '#pragma omp declare simd' directive. Initial parsing/sema/serialization/deserialization support for '#pragma omp declare simd' directive. The 'declare simd' construct can be applied to a function to enable the creation of one or more versions that can process multiple arguments using SIMD instructions from a single invocation from a SIMD loop. If the function has any declarations, then the declare simd construct for any declaration that has one must be equivalent to the one specified for the definition. Otherwise, the result is unspecified. This pragma can be applied many times to the same declaration. Internally this pragma is represented as an attribute. But we need special processing for this pragma because it must be used before function declaration, this directive is applied to. Differential Revision: http://reviews.llvm.org/D10599 llvm-svn: 264853
2016-03-30 18:43:55 +08:00
DeclSpec::TST TagType, Decl *Tag) {
[OpenMP] Support OpenMP 5.1 attributes 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.
2021-07-12 18:51:19 +08:00
assert(Tok.isOneOf(tok::annot_pragma_openmp, tok::annot_attr_openmp) &&
"Not an OpenMP directive!");
[OPENMP]Fix skipping of functions body. When parsing the code with OpenMP and the function's body must be skipped, need to skip also OpenMP annotation tokens. Otherwise the counters for braces/parens are unbalanced and parsing fails.
2019-12-14 05:05:30 +08:00
ParsingOpenMPDirectiveRAII DirScope(*this);
Replaced bool parameters in SkipUntil function with single bit-based parameter. llvm-svn: 194994
2013-11-18 16:17:37 +08:00
ParenBraceBracketBalancer BalancerRAIIObj(*this);
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 14:34:35 +08:00
[OPENMP]Allow using of members in standalone declaration pragmas. If standalone OpenMP declaration pragma, like declare mapper or declare reduction, is declared in the class context, it may reference a member (data or function) in its internal expressions/statements. So, the parsing of such pragmas must be dalayed just like the parsing of the member initializers/definitions before the completion of the class declaration.
2020-01-08 02:39:18 +08:00
SourceLocation Loc;
OpenMPDirectiveKind DKind;
if (Delayed) {
TentativeParsingAction TPA(*this);
Loc = ConsumeAnnotationToken();
DKind = parseOpenMPDirectiveKind(*this);
if (DKind == OMPD_declare_reduction || DKind == OMPD_declare_mapper) {
// Need to delay parsing until completion of the parent class.
TPA.Revert();
CachedTokens Toks;
unsigned Cnt = 1;
Toks.push_back(Tok);
while (Cnt && Tok.isNot(tok::eof)) {
(void)ConsumeAnyToken();
[OpenMP] Support OpenMP 5.1 attributes 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.
2021-07-12 18:51:19 +08:00
if (Tok.isOneOf(tok::annot_pragma_openmp, tok::annot_attr_openmp))
[OPENMP]Allow using of members in standalone declaration pragmas. If standalone OpenMP declaration pragma, like declare mapper or declare reduction, is declared in the class context, it may reference a member (data or function) in its internal expressions/statements. So, the parsing of such pragmas must be dalayed just like the parsing of the member initializers/definitions before the completion of the class declaration.
2020-01-08 02:39:18 +08:00
++Cnt;
else if (Tok.is(tok::annot_pragma_openmp_end))
--Cnt;
Toks.push_back(Tok);
}
// Skip last annot_pragma_openmp_end.
if (Cnt == 0)
(void)ConsumeAnyToken();
auto *LP = new LateParsedPragma(this, AS);
LP->takeToks(Toks);
getCurrentClass().LateParsedDeclarations.push_back(LP);
return nullptr;
}
TPA.Commit();
} else {
Loc = ConsumeAnnotationToken();
DKind = parseOpenMPDirectiveKind(*this);
}
OpenMP threadprivate with qualified names. llvm-svn: 181683
2013-05-13 12:18:18 +08:00
switch (DKind) {
[OpenMP] Parse+Sema for '#pragma omp declare target' syntax version 4.5 Support OpenMP version 4.5 syntax for #pragma omp declare target. Syntax: #pragma omp declare target (extended-list) new-line or #pragma omp declare target clause[ [,] clause ... ] new-line Where clause is one of the following: to(extended-list) link(list) Differential Revision: http://reviews.llvm.org/D20011 llvm-svn: 268925
2016-05-09 22:59:13 +08:00
case OMPD_threadprivate: {
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 14:34:35 +08:00
ConsumeToken();
[OPENMP 5.0]Add initial support for 'allocate' directive. Added parsing/sema analysis/serialization/deserialization support for 'allocate' directive. llvm-svn: 355614
2019-03-08 01:54:44 +08:00
DeclDirectiveListParserHelper Helper(this, DKind);
if (!ParseOpenMPSimpleVarList(DKind, Helper,
/*AllowScopeSpecifier=*/true)) {
[OpenMP][NFC] Outline common functionality (skipUntilPragmaOpenMPEnd) The same code was repeated multiple times, we put it in a function now.
2020-02-22 03:48:56 +08:00
skipUntilPragmaOpenMPEnd(DKind);
OpenMP threadprivate with qualified names. llvm-svn: 181683
2013-05-13 12:18:18 +08:00
// Skip the last annot_pragma_openmp_end.
Fix the location of "missing ';'" suggestions after annotation tokens. We were incorrectly setting PrevTokLocation to the first token in the annotation token instead of the last when consuming it. To fix this without adding a complex switch to the hot path through ConsumeToken, we now have a ConsumeAnnotationToken function for consuming annotation tokens in addition to the other Consume*Token special case functions. llvm-svn: 303372
2017-05-19 03:21:48 +08:00
ConsumeAnnotationToken();
[OpenMP] Parse+Sema for '#pragma omp declare target' syntax version 4.5 Support OpenMP version 4.5 syntax for #pragma omp declare target. Syntax: #pragma omp declare target (extended-list) new-line or #pragma omp declare target clause[ [,] clause ... ] new-line Where clause is one of the following: to(extended-list) link(list) Differential Revision: http://reviews.llvm.org/D20011 llvm-svn: 268925
2016-05-09 22:59:13 +08:00
return Actions.ActOnOpenMPThreadprivateDirective(Loc,
Helper.getIdentifiers());
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 14:34:35 +08:00
}
break;
[OpenMP] Parse+Sema for '#pragma omp declare target' syntax version 4.5 Support OpenMP version 4.5 syntax for #pragma omp declare target. Syntax: #pragma omp declare target (extended-list) new-line or #pragma omp declare target clause[ [,] clause ... ] new-line Where clause is one of the following: to(extended-list) link(list) Differential Revision: http://reviews.llvm.org/D20011 llvm-svn: 268925
2016-05-09 22:59:13 +08:00
}
[OPENMP 5.0]Add initial support for 'allocate' directive. Added parsing/sema analysis/serialization/deserialization support for 'allocate' directive. llvm-svn: 355614
2019-03-08 01:54:44 +08:00
case OMPD_allocate: {
ConsumeToken();
DeclDirectiveListParserHelper Helper(this, DKind);
if (!ParseOpenMPSimpleVarList(DKind, Helper,
/*AllowScopeSpecifier=*/true)) {
[OPENMP 5.0]Initial support for 'allocator' clause. Added parsing/sema analysis/serialization/deserialization for the 'allocator' clause of the 'allocate' directive. llvm-svn: 355952
2019-03-13 02:52:33 +08:00
SmallVector<OMPClause *, 1> Clauses;
[OPENMP 5.0]Add initial support for 'allocate' directive. Added parsing/sema analysis/serialization/deserialization support for 'allocate' directive. llvm-svn: 355614
2019-03-08 01:54:44 +08:00
if (Tok.isNot(tok::annot_pragma_openmp_end)) {
[OPENMP 5.0]Initial support for 'allocator' clause. Added parsing/sema analysis/serialization/deserialization for the 'allocator' clause of the 'allocate' directive. llvm-svn: 355952
2019-03-13 02:52:33 +08:00
SmallVector<llvm::PointerIntPair<OMPClause *, 1, bool>,
[openmp] Base of tablegen generated OpenMP common declaration Summary: As discussed previously when landing patch for OpenMP in Flang, the idea is to share common part of the OpenMP declaration between the different Frontend. While doing this it was thought that moving to tablegen instead of Macros will also give a cleaner and more powerful way of generating these declaration. This first part of a future series of patches is setting up the base .td file for DirectiveLanguage as well as the OpenMP version of it. The base file is meant to be used by other directive language such as OpenACC. In this first patch, the Directive and Clause enums are generated with tablegen instead of the macros on OMPConstants.h. The next pacth will extend this to other enum and move the Flang frontend to use it. Reviewers: jdoerfert, DavidTruby, fghanim, ABataev, jdenny, hfinkel, jhuber6, kiranchandramohan, kiranktp Reviewed By: jdoerfert, jdenny Subscribers: arphaman, martong, cfe-commits, mgorny, yaxunl, hiraditya, guansong, jfb, sstefan1, aaron.ballman, llvm-commits Tags: #llvm, #openmp, #clang Differential Revision: https://reviews.llvm.org/D81736
2020-06-23 21:29:50 +08:00
llvm::omp::Clause_enumSize + 1>
FirstClauses(llvm::omp::Clause_enumSize + 1);
[OPENMP 5.0]Initial support for 'allocator' clause. Added parsing/sema analysis/serialization/deserialization for the 'allocator' clause of the 'allocate' directive. llvm-svn: 355952
2019-03-13 02:52:33 +08:00
while (Tok.isNot(tok::annot_pragma_openmp_end)) {
OpenMPClauseKind CKind =
Tok.isAnnotation() ? OMPC_unknown
: getOpenMPClauseKind(PP.getSpelling(Tok));
Actions.StartOpenMPClause(CKind);
[OpenMP][NFCI] Move OpenMP clause information to `lib/Frontend/OpenMP` This is a cleanup and normalization patch that also enables reuse with Flang later on. A follow up will clean up and move the directive -> clauses mapping. Reviewed By: fghanim Differential Revision: https://reviews.llvm.org/D77112
2020-03-31 08:58:40 +08:00
OMPClause *Clause = ParseOpenMPClause(
OMPD_allocate, CKind, !FirstClauses[unsigned(CKind)].getInt());
[OPENMP 5.0]Initial support for 'allocator' clause. Added parsing/sema analysis/serialization/deserialization for the 'allocator' clause of the 'allocate' directive. llvm-svn: 355952
2019-03-13 02:52:33 +08:00
SkipUntil(tok::comma, tok::identifier, tok::annot_pragma_openmp_end,
StopBeforeMatch);
[OpenMP][NFCI] Move OpenMP clause information to `lib/Frontend/OpenMP` This is a cleanup and normalization patch that also enables reuse with Flang later on. A follow up will clean up and move the directive -> clauses mapping. Reviewed By: fghanim Differential Revision: https://reviews.llvm.org/D77112
2020-03-31 08:58:40 +08:00
FirstClauses[unsigned(CKind)].setInt(true);
[OPENMP 5.0]Initial support for 'allocator' clause. Added parsing/sema analysis/serialization/deserialization for the 'allocator' clause of the 'allocate' directive. llvm-svn: 355952
2019-03-13 02:52:33 +08:00
if (Clause != nullptr)
Clauses.push_back(Clause);
if (Tok.is(tok::annot_pragma_openmp_end)) {
Actions.EndOpenMPClause();
break;
}
// Skip ',' if any.
if (Tok.is(tok::comma))
ConsumeToken();
Actions.EndOpenMPClause();
}
[OpenMP][NFC] Outline common functionality (skipUntilPragmaOpenMPEnd) The same code was repeated multiple times, we put it in a function now.
2020-02-22 03:48:56 +08:00
skipUntilPragmaOpenMPEnd(DKind);
[OPENMP 5.0]Add initial support for 'allocate' directive. Added parsing/sema analysis/serialization/deserialization support for 'allocate' directive. llvm-svn: 355614
2019-03-08 01:54:44 +08:00
}
// Skip the last annot_pragma_openmp_end.
ConsumeAnnotationToken();
[OPENMP 5.0]Initial support for 'allocator' clause. Added parsing/sema analysis/serialization/deserialization for the 'allocator' clause of the 'allocate' directive. llvm-svn: 355952
2019-03-13 02:52:33 +08:00
return Actions.ActOnOpenMPAllocateDirective(Loc, Helper.getIdentifiers(),
Clauses);
[OPENMP 5.0]Add initial support for 'allocate' directive. Added parsing/sema analysis/serialization/deserialization support for 'allocate' directive. llvm-svn: 355614
2019-03-08 01:54:44 +08:00
}
break;
}
[OPENMP] Add support for OMP5 requires directive + unified_address clause Add support for OMP5.0 requires directive and unified_address clause. Patches to follow will include support for additional clauses. Differential Revision: https://reviews.llvm.org/D52359 llvm-svn: 343063
2018-09-26 12:28:39 +08:00
case OMPD_requires: {
SourceLocation StartLoc = ConsumeToken();
SmallVector<OMPClause *, 5> Clauses;
[OpenMP][NFCI] Move OpenMP clause information to `lib/Frontend/OpenMP` This is a cleanup and normalization patch that also enables reuse with Flang later on. A follow up will clean up and move the directive -> clauses mapping. Reviewed By: fghanim Differential Revision: https://reviews.llvm.org/D77112
2020-03-31 08:58:40 +08:00
SmallVector<llvm::PointerIntPair<OMPClause *, 1, bool>,
[openmp] Base of tablegen generated OpenMP common declaration Summary: As discussed previously when landing patch for OpenMP in Flang, the idea is to share common part of the OpenMP declaration between the different Frontend. While doing this it was thought that moving to tablegen instead of Macros will also give a cleaner and more powerful way of generating these declaration. This first part of a future series of patches is setting up the base .td file for DirectiveLanguage as well as the OpenMP version of it. The base file is meant to be used by other directive language such as OpenACC. In this first patch, the Directive and Clause enums are generated with tablegen instead of the macros on OMPConstants.h. The next pacth will extend this to other enum and move the Flang frontend to use it. Reviewers: jdoerfert, DavidTruby, fghanim, ABataev, jdenny, hfinkel, jhuber6, kiranchandramohan, kiranktp Reviewed By: jdoerfert, jdenny Subscribers: arphaman, martong, cfe-commits, mgorny, yaxunl, hiraditya, guansong, jfb, sstefan1, aaron.ballman, llvm-commits Tags: #llvm, #openmp, #clang Differential Revision: https://reviews.llvm.org/D81736
2020-06-23 21:29:50 +08:00
llvm::omp::Clause_enumSize + 1>
FirstClauses(llvm::omp::Clause_enumSize + 1);
[OPENMP] Add support for OMP5 requires directive + unified_address clause Add support for OMP5.0 requires directive and unified_address clause. Patches to follow will include support for additional clauses. Differential Revision: https://reviews.llvm.org/D52359 llvm-svn: 343063
2018-09-26 12:28:39 +08:00
if (Tok.is(tok::annot_pragma_openmp_end)) {
[CodeComplete] Propagate preferred type for function arguments in more cases Summary: See the added test for some new cases. This change also removes special code completion calls inside the ParseExpressionList function now that we properly propagate expected type to the function responsible for parsing elements of the expression list (ParseAssignmentExpression). Reviewers: kadircet Reviewed By: kadircet Subscribers: xbolva00, jdoerfert, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58541 llvm-svn: 354864
2019-02-26 19:01:50 +08:00
Diag(Tok, diag::err_omp_expected_clause)
[OPENMP] Add support for OMP5 requires directive + unified_address clause Add support for OMP5.0 requires directive and unified_address clause. Patches to follow will include support for additional clauses. Differential Revision: https://reviews.llvm.org/D52359 llvm-svn: 343063
2018-09-26 12:28:39 +08:00
<< getOpenMPDirectiveName(OMPD_requires);
break;
}
while (Tok.isNot(tok::annot_pragma_openmp_end)) {
OpenMPClauseKind CKind = Tok.isAnnotation()
? OMPC_unknown
: getOpenMPClauseKind(PP.getSpelling(Tok));
Actions.StartOpenMPClause(CKind);
[OpenMP][NFCI] Move OpenMP clause information to `lib/Frontend/OpenMP` This is a cleanup and normalization patch that also enables reuse with Flang later on. A follow up will clean up and move the directive -> clauses mapping. Reviewed By: fghanim Differential Revision: https://reviews.llvm.org/D77112
2020-03-31 08:58:40 +08:00
OMPClause *Clause = ParseOpenMPClause(
OMPD_requires, CKind, !FirstClauses[unsigned(CKind)].getInt());
[OPENMP 5.0]Initial support for 'allocator' clause. Added parsing/sema analysis/serialization/deserialization for the 'allocator' clause of the 'allocate' directive. llvm-svn: 355952
2019-03-13 02:52:33 +08:00
SkipUntil(tok::comma, tok::identifier, tok::annot_pragma_openmp_end,
StopBeforeMatch);
[OpenMP][NFCI] Move OpenMP clause information to `lib/Frontend/OpenMP` This is a cleanup and normalization patch that also enables reuse with Flang later on. A follow up will clean up and move the directive -> clauses mapping. Reviewed By: fghanim Differential Revision: https://reviews.llvm.org/D77112
2020-03-31 08:58:40 +08:00
FirstClauses[unsigned(CKind)].setInt(true);
[OPENMP] Add support for OMP5 requires directive + unified_address clause Add support for OMP5.0 requires directive and unified_address clause. Patches to follow will include support for additional clauses. Differential Revision: https://reviews.llvm.org/D52359 llvm-svn: 343063
2018-09-26 12:28:39 +08:00
if (Clause != nullptr)
Clauses.push_back(Clause);
if (Tok.is(tok::annot_pragma_openmp_end)) {
Actions.EndOpenMPClause();
break;
}
// Skip ',' if any.
if (Tok.is(tok::comma))
ConsumeToken();
Actions.EndOpenMPClause();
}
// Consume final annot_pragma_openmp_end
[OPENMP50]Full handling of atomic_default_mem_order in requires directive. According to OpenMP 5.0, The atomic_default_mem_order clause specifies the default memory ordering behavior for atomic constructs that must be provided by an implementation. If the default memory ordering is specified as seq_cst, all atomic constructs on which memory-order-clause is not specified behave as if the seq_cst clause appears. If the default memory ordering is specified as relaxed, all atomic constructs on which memory-order-clause is not specified behave as if the relaxed clause appears. If the default memory ordering is specified as acq_rel, atomic constructs on which memory-order-clause is not specified behave as if the release clause appears if the atomic write or atomic update operation is specified, as if the acquire clause appears if the atomic read operation is specified, and as if the acq_rel clause appears if the atomic captured update operation is specified.
2020-02-12 04:15:21 +08:00
if (Clauses.empty()) {
[OPENMP] Add support for OMP5 requires directive + unified_address clause Add support for OMP5.0 requires directive and unified_address clause. Patches to follow will include support for additional clauses. Differential Revision: https://reviews.llvm.org/D52359 llvm-svn: 343063
2018-09-26 12:28:39 +08:00
Diag(Tok, diag::err_omp_expected_clause)
<< getOpenMPDirectiveName(OMPD_requires);
ConsumeAnnotationToken();
return nullptr;
}
ConsumeAnnotationToken();
return Actions.ActOnOpenMPRequiresDirective(StartLoc, Clauses);
}
[OpenMP] Add initial support for `omp [begin/end] assumes` The `assumes` directive is an OpenMP 5.1 feature that allows the user to provide assumptions to the optimizer. Assumptions can refer to directives (`absent` and `contains` clauses), expressions (`holds` clause), or generic properties (`no_openmp_routines`, `ext_ABCD`, ...). The `assumes` spelling is used for assumptions in the global scope while `assume` is used for executable contexts with an associated structured block. This patch only implements the global spellings. While clauses with arguments are "accepted" by the parser, they will simply be ignored for now. The implementation lowers the assumptions directly to the `AssumptionAttr`. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D91980
2020-11-24 01:48:59 +08:00
case OMPD_assumes:
case OMPD_begin_assumes:
ParseOpenMPAssumesDirective(DKind, ConsumeToken());
break;
case OMPD_end_assumes:
ParseOpenMPEndAssumesDirective(ConsumeToken());
break;
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
case OMPD_declare_reduction:
ConsumeToken();
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-24 03:53:05 +08:00
if (DeclGroupPtrTy Res = ParseOpenMPDeclareReductionDirective(AS)) {
[OpenMP][NFC] Outline common functionality (skipUntilPragmaOpenMPEnd) The same code was repeated multiple times, we put it in a function now.
2020-02-22 03:48:56 +08:00
skipUntilPragmaOpenMPEnd(OMPD_declare_reduction);
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
// Skip the last annot_pragma_openmp_end.
Fix the location of "missing ';'" suggestions after annotation tokens. We were incorrectly setting PrevTokLocation to the first token in the annotation token instead of the last when consuming it. To fix this without adding a complex switch to the hot path through ConsumeToken, we now have a ConsumeAnnotationToken function for consuming annotation tokens in addition to the other Consume*Token special case functions. llvm-svn: 303372
2017-05-19 03:21:48 +08:00
ConsumeAnnotationToken();
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
return Res;
}
break;
[OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive. This patch implements parsing and sema for "omp declare mapper" directive. User defined mapper, i.e., declare mapper directive, is a new feature in OpenMP 5.0. It is introduced to extend existing map clauses for the purpose of simplifying the copy of complex data structures between host and device (i.e., deep copy). An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(struct S s) map(s, s.d[0:s.len]) // Memory region that d points to is also mapped using this mapper. Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D56326 llvm-svn: 352906
2019-02-02 04:25:04 +08:00
case OMPD_declare_mapper: {
ConsumeToken();
if (DeclGroupPtrTy Res = ParseOpenMPDeclareMapperDirective(AS)) {
// Skip the last annot_pragma_openmp_end.
ConsumeAnnotationToken();
return Res;
}
break;
}
[OpenMP] `omp begin/end declare variant` - part 1, parsing This is the first part extracted from D71179 and cleaned up. This patch provides parsing support for `omp begin/end declare variant`, as defined in OpenMP technical report 8 (TR8) [0]. A major purpose of this patch is to provide proper math.h/cmath support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D74941
2020-02-21 09:50:47 +08:00
case OMPD_begin_declare_variant: {
// The syntax is:
// { #pragma omp begin declare variant clause }
// <function-declaration-or-definition-sequence>
// { #pragma omp end declare variant }
//
ConsumeToken();
[OpenMP] Support nested OpenMP context selectors (declare variant) Due to `omp begin/end declare variant`, OpenMP context selectors can be nested. This patch adds initial support for this so we can use it for target math variants. We should improve the detection of "equivalent" scores and user conditions, we should also revisit the data structures of the OMPTraitInfo object, however, both are not pressing issues right now. Reviewed By: JonChesterfield Differential Revision: https://reviews.llvm.org/D85877
2020-08-13 14:05:51 +08:00
OMPTraitInfo *ParentTI = Actions.getOMPTraitInfoForSurroundingScope();
ASTContext &ASTCtx = Actions.getASTContext();
OMPTraitInfo &TI = ASTCtx.getNewOMPTraitInfo();
[OPENMP51]Initial parsing/sema for adjust_args clause for 'declare variant' Adds initial parsing and sema for the 'adjust_args' clause. Note that an AST clause is not created as it instead adds its expressions to the OMPDeclareVariantAttr. Differential Revision: https://reviews.llvm.org/D99905
2021-10-13 05:55:00 +08:00
if (parseOMPDeclareVariantMatchClause(Loc, TI, ParentTI)) {
while (!SkipUntil(tok::annot_pragma_openmp_end, Parser::StopBeforeMatch))
;
// Skip the last annot_pragma_openmp_end.
(void)ConsumeAnnotationToken();
[OpenMP] `omp begin/end declare variant` - part 1, parsing This is the first part extracted from D71179 and cleaned up. This patch provides parsing support for `omp begin/end declare variant`, as defined in OpenMP technical report 8 (TR8) [0]. A major purpose of this patch is to provide proper math.h/cmath support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D74941
2020-02-21 09:50:47 +08:00
break;
[OPENMP51]Initial parsing/sema for adjust_args clause for 'declare variant' Adds initial parsing and sema for the 'adjust_args' clause. Note that an AST clause is not created as it instead adds its expressions to the OMPDeclareVariantAttr. Differential Revision: https://reviews.llvm.org/D99905
2021-10-13 05:55:00 +08:00
}
[OpenMP] `omp begin/end declare variant` - part 1, parsing This is the first part extracted from D71179 and cleaned up. This patch provides parsing support for `omp begin/end declare variant`, as defined in OpenMP technical report 8 (TR8) [0]. A major purpose of this patch is to provide proper math.h/cmath support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D74941
2020-02-21 09:50:47 +08:00
// Skip last tokens.
skipUntilPragmaOpenMPEnd(OMPD_begin_declare_variant);
[OPENMP]Fix PR46357: Do not allow types declarations in pragmas. Summary: Compiler may erroneously treat current context in OpenMP pragmas as the context where new type declaration/definition is allowed. But the declartation/definition of the new types in OpenMP pragmas should not be allowed. Reviewers: jdoerfert Subscribers: yaxunl, guansong, sstefan1, cfe-commits, caomhin Tags: #clang Differential Revision: https://reviews.llvm.org/D82019
2020-06-17 23:02:49 +08:00
ParsingOpenMPDirectiveRAII NormalScope(*this, /*Value=*/false);
[OpenMP] `omp begin/end declare variant` - part 1, parsing This is the first part extracted from D71179 and cleaned up. This patch provides parsing support for `omp begin/end declare variant`, as defined in OpenMP technical report 8 (TR8) [0]. A major purpose of this patch is to provide proper math.h/cmath support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D74941
2020-02-21 09:50:47 +08:00
VariantMatchInfo VMI;
[OpenMP] Add match_{all,any,none} declare variant selector extensions. By default, all traits in the OpenMP context selector have to match for it to be acceptable. Though, we sometimes want a single property out of multiple to match (=any) or no match at all (=none). We offer these choices as extensions via `implementation={extension(match_{all,any,none})}` to the user. The choice will affect the entire context selector not only the traits following the match property. The first user will be D75788. There we can replace ``` #pragma omp begin declare variant match(device={arch(nvptx64)}) #define __CUDA__ #include <__clang_cuda_cmath.h> // TODO: Hack until we support an extension to the match clause that allows "or". #undef __CLANG_CUDA_CMATH_H__ #undef __CUDA__ #pragma omp end declare variant #pragma omp begin declare variant match(device={arch(nvptx)}) #define __CUDA__ #include <__clang_cuda_cmath.h> #undef __CUDA__ #pragma omp end declare variant ``` with the much simpler ``` #pragma omp begin declare variant match(device={arch(nvptx, nvptx64)}, implementation={extension(match_any)}) #define __CUDA__ #include <__clang_cuda_cmath.h> #undef __CUDA__ #pragma omp end declare variant ``` Reviewed By: mikerice Differential Revision: https://reviews.llvm.org/D77414
2020-04-04 00:29:53 +08:00
TI.getAsVariantMatchInfo(ASTCtx, VMI);
[OpenMP] Allow traits for the OpenMP context selector `isa` It was unclear what `isa` was supposed to mean so we did not provide any traits for this context selector. With this patch we will allow *any* string or identifier. We use the target attribute and target info to determine if the trait matches. In other words, we will check if the provided value is a target feature that is available (at the call site). Fixes PR46338 Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D83281
2020-07-07 14:08:03 +08:00
std::function<void(StringRef)> DiagUnknownTrait = [this, Loc](
StringRef ISATrait) {
// TODO Track the selector locations in a way that is accessible here to
// improve the diagnostic location.
Diag(Loc, diag::warn_unknown_begin_declare_variant_isa_trait) << ISATrait;
};
[OpenMP] Support construct trait set for Clang This patch supports construct trait set selector by using the existed declare variant infrastructure inside `OMPContext` and simd selector is currently not supported. The goal of this patch is to pass the declare variant test inside sollve test suite. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D109635
2021-09-17 00:28:31 +08:00
TargetOMPContext OMPCtx(
ASTCtx, std::move(DiagUnknownTrait),
/* CurrentFunctionDecl */ nullptr,
/* ConstructTraits */ ArrayRef<llvm::omp::TraitProperty>());
[OpenMP] `omp begin/end declare variant` - part 1, parsing This is the first part extracted from D71179 and cleaned up. This patch provides parsing support for `omp begin/end declare variant`, as defined in OpenMP technical report 8 (TR8) [0]. A major purpose of this patch is to provide proper math.h/cmath support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D74941
2020-02-21 09:50:47 +08:00
[OpenMP] Add match_{all,any,none} declare variant selector extensions. By default, all traits in the OpenMP context selector have to match for it to be acceptable. Though, we sometimes want a single property out of multiple to match (=any) or no match at all (=none). We offer these choices as extensions via `implementation={extension(match_{all,any,none})}` to the user. The choice will affect the entire context selector not only the traits following the match property. The first user will be D75788. There we can replace ``` #pragma omp begin declare variant match(device={arch(nvptx64)}) #define __CUDA__ #include <__clang_cuda_cmath.h> // TODO: Hack until we support an extension to the match clause that allows "or". #undef __CLANG_CUDA_CMATH_H__ #undef __CUDA__ #pragma omp end declare variant #pragma omp begin declare variant match(device={arch(nvptx)}) #define __CUDA__ #include <__clang_cuda_cmath.h> #undef __CUDA__ #pragma omp end declare variant ``` with the much simpler ``` #pragma omp begin declare variant match(device={arch(nvptx, nvptx64)}, implementation={extension(match_any)}) #define __CUDA__ #include <__clang_cuda_cmath.h> #undef __CUDA__ #pragma omp end declare variant ``` Reviewed By: mikerice Differential Revision: https://reviews.llvm.org/D77414
2020-04-04 00:29:53 +08:00
if (isVariantApplicableInContext(VMI, OMPCtx, /* DeviceSetOnly */ true)) {
[OpenMP] `omp begin/end declare variant` - part 2, sema ("+CG") This is the second part loosely extracted from D71179 and cleaned up. This patch provides semantic analysis support for `omp begin/end declare variant`, mostly as defined in OpenMP technical report 8 (TR8) [0]. The sema handling makes code generation obsolete as we generate "the right" calls that can just be handled as usual. This handling also applies to the existing, albeit problematic, `omp declare variant support`. As a consequence a lot of unneeded code generation and complexity is removed. A major purpose of this patch is to provide proper `math.h`/`cmath` support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. The logic is as follows: If we have seen a `#pragma omp begin declare variant match(<SELECTOR>)` but not the corresponding `end declare variant`, and we find a function definition we will: 1) Create a function declaration for the definition we were about to generate. 2) Create a function definition but with a mangled name (according to `<SELECTOR>`). 3) Annotate the declaration with the `OMPDeclareVariantAttr`, the same one used already for `omp declare variant`, using and the mangled function definition as specialization for the context defined by `<SELECTOR>`. When a call is created we inspect it. If the target has an `OMPDeclareVariantAttr` attribute we try to specialize the call. To this end, all variants are checked, the best applicable one is picked and a new call to the specialization is created. The new call is used instead of the original one to the base function. To keep the AST printing and tooling possible we utilize the PseudoObjectExpr. The original call is the syntactic expression, the specialized call is the semantic expression. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim, aaron.ballman Subscribers: bollu, guansong, openmp-commits, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D75779
2020-02-26 06:04:06 +08:00
Actions.ActOnOpenMPBeginDeclareVariant(Loc, TI);
[OpenMP] `omp begin/end declare variant` - part 1, parsing This is the first part extracted from D71179 and cleaned up. This patch provides parsing support for `omp begin/end declare variant`, as defined in OpenMP technical report 8 (TR8) [0]. A major purpose of this patch is to provide proper math.h/cmath support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D74941
2020-02-21 09:50:47 +08:00
break;
[OpenMP] `omp begin/end declare variant` - part 2, sema ("+CG") This is the second part loosely extracted from D71179 and cleaned up. This patch provides semantic analysis support for `omp begin/end declare variant`, mostly as defined in OpenMP technical report 8 (TR8) [0]. The sema handling makes code generation obsolete as we generate "the right" calls that can just be handled as usual. This handling also applies to the existing, albeit problematic, `omp declare variant support`. As a consequence a lot of unneeded code generation and complexity is removed. A major purpose of this patch is to provide proper `math.h`/`cmath` support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. The logic is as follows: If we have seen a `#pragma omp begin declare variant match(<SELECTOR>)` but not the corresponding `end declare variant`, and we find a function definition we will: 1) Create a function declaration for the definition we were about to generate. 2) Create a function definition but with a mangled name (according to `<SELECTOR>`). 3) Annotate the declaration with the `OMPDeclareVariantAttr`, the same one used already for `omp declare variant`, using and the mangled function definition as specialization for the context defined by `<SELECTOR>`. When a call is created we inspect it. If the target has an `OMPDeclareVariantAttr` attribute we try to specialize the call. To this end, all variants are checked, the best applicable one is picked and a new call to the specialization is created. The new call is used instead of the original one to the base function. To keep the AST printing and tooling possible we utilize the PseudoObjectExpr. The original call is the syntactic expression, the specialized call is the semantic expression. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim, aaron.ballman Subscribers: bollu, guansong, openmp-commits, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D75779
2020-02-26 06:04:06 +08:00
}
[OpenMP] `omp begin/end declare variant` - part 1, parsing This is the first part extracted from D71179 and cleaned up. This patch provides parsing support for `omp begin/end declare variant`, as defined in OpenMP technical report 8 (TR8) [0]. A major purpose of this patch is to provide proper math.h/cmath support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D74941
2020-02-21 09:50:47 +08:00
// Elide all the code till the matching end declare variant was found.
unsigned Nesting = 1;
SourceLocation DKLoc;
OpenMPDirectiveKind DK = OMPD_unknown;
do {
DKLoc = Tok.getLocation();
DK = parseOpenMPDirectiveKind(*this);
if (DK == OMPD_end_declare_variant)
--Nesting;
else if (DK == OMPD_begin_declare_variant)
++Nesting;
if (!Nesting || isEofOrEom())
break;
ConsumeAnyToken();
} while (true);
parseOMPEndDirective(OMPD_begin_declare_variant, OMPD_end_declare_variant,
DK, Loc, DKLoc, /* SkipUntilOpenMPEnd */ true);
if (isEofOrEom())
return nullptr;
break;
}
[OpenMP] `omp begin/end declare variant` - part 2, sema ("+CG") This is the second part loosely extracted from D71179 and cleaned up. This patch provides semantic analysis support for `omp begin/end declare variant`, mostly as defined in OpenMP technical report 8 (TR8) [0]. The sema handling makes code generation obsolete as we generate "the right" calls that can just be handled as usual. This handling also applies to the existing, albeit problematic, `omp declare variant support`. As a consequence a lot of unneeded code generation and complexity is removed. A major purpose of this patch is to provide proper `math.h`/`cmath` support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. The logic is as follows: If we have seen a `#pragma omp begin declare variant match(<SELECTOR>)` but not the corresponding `end declare variant`, and we find a function definition we will: 1) Create a function declaration for the definition we were about to generate. 2) Create a function definition but with a mangled name (according to `<SELECTOR>`). 3) Annotate the declaration with the `OMPDeclareVariantAttr`, the same one used already for `omp declare variant`, using and the mangled function definition as specialization for the context defined by `<SELECTOR>`. When a call is created we inspect it. If the target has an `OMPDeclareVariantAttr` attribute we try to specialize the call. To this end, all variants are checked, the best applicable one is picked and a new call to the specialization is created. The new call is used instead of the original one to the base function. To keep the AST printing and tooling possible we utilize the PseudoObjectExpr. The original call is the syntactic expression, the specialized call is the semantic expression. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim, aaron.ballman Subscribers: bollu, guansong, openmp-commits, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D75779
2020-02-26 06:04:06 +08:00
case OMPD_end_declare_variant: {
if (Actions.isInOpenMPDeclareVariantScope())
Actions.ActOnOpenMPEndDeclareVariant();
else
Diag(Loc, diag::err_expected_begin_declare_variant);
[OpenMP] `omp begin/end declare variant` - part 1, parsing This is the first part extracted from D71179 and cleaned up. This patch provides parsing support for `omp begin/end declare variant`, as defined in OpenMP technical report 8 (TR8) [0]. A major purpose of this patch is to provide proper math.h/cmath support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D74941
2020-02-21 09:50:47 +08:00
ConsumeToken();
break;
[OpenMP] `omp begin/end declare variant` - part 2, sema ("+CG") This is the second part loosely extracted from D71179 and cleaned up. This patch provides semantic analysis support for `omp begin/end declare variant`, mostly as defined in OpenMP technical report 8 (TR8) [0]. The sema handling makes code generation obsolete as we generate "the right" calls that can just be handled as usual. This handling also applies to the existing, albeit problematic, `omp declare variant support`. As a consequence a lot of unneeded code generation and complexity is removed. A major purpose of this patch is to provide proper `math.h`/`cmath` support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. The logic is as follows: If we have seen a `#pragma omp begin declare variant match(<SELECTOR>)` but not the corresponding `end declare variant`, and we find a function definition we will: 1) Create a function declaration for the definition we were about to generate. 2) Create a function definition but with a mangled name (according to `<SELECTOR>`). 3) Annotate the declaration with the `OMPDeclareVariantAttr`, the same one used already for `omp declare variant`, using and the mangled function definition as specialization for the context defined by `<SELECTOR>`. When a call is created we inspect it. If the target has an `OMPDeclareVariantAttr` attribute we try to specialize the call. To this end, all variants are checked, the best applicable one is picked and a new call to the specialization is created. The new call is used instead of the original one to the base function. To keep the AST printing and tooling possible we utilize the PseudoObjectExpr. The original call is the syntactic expression, the specialized call is the semantic expression. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim, aaron.ballman Subscribers: bollu, guansong, openmp-commits, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D75779
2020-02-26 06:04:06 +08:00
}
[OPENMP5.0]Add basic support for declare variant directive. Added basic support for declare variant directive and its match clause with user context selector. llvm-svn: 371892
2019-09-14 04:18:17 +08:00
case OMPD_declare_variant:
[OPENMP 4.0] Initial support for '#pragma omp declare simd' directive. Initial parsing/sema/serialization/deserialization support for '#pragma omp declare simd' directive. The 'declare simd' construct can be applied to a function to enable the creation of one or more versions that can process multiple arguments using SIMD instructions from a single invocation from a SIMD loop. If the function has any declarations, then the declare simd construct for any declaration that has one must be equivalent to the one specified for the definition. Otherwise, the result is unspecified. This pragma can be applied many times to the same declaration. Internally this pragma is represented as an attribute. But we need special processing for this pragma because it must be used before function declaration, this directive is applied to. Differential Revision: http://reviews.llvm.org/D10599 llvm-svn: 264853
2016-03-30 18:43:55 +08:00
case OMPD_declare_simd: {
// The syntax is:
[OPENMP5.0]Add basic support for declare variant directive. Added basic support for declare variant directive and its match clause with user context selector. llvm-svn: 371892
2019-09-14 04:18:17 +08:00
// { #pragma omp declare {simd|variant} }
[OPENMP 4.0] Initial support for '#pragma omp declare simd' directive. Initial parsing/sema/serialization/deserialization support for '#pragma omp declare simd' directive. The 'declare simd' construct can be applied to a function to enable the creation of one or more versions that can process multiple arguments using SIMD instructions from a single invocation from a SIMD loop. If the function has any declarations, then the declare simd construct for any declaration that has one must be equivalent to the one specified for the definition. Otherwise, the result is unspecified. This pragma can be applied many times to the same declaration. Internally this pragma is represented as an attribute. But we need special processing for this pragma because it must be used before function declaration, this directive is applied to. Differential Revision: http://reviews.llvm.org/D10599 llvm-svn: 264853
2016-03-30 18:43:55 +08:00
// <function-declaration-or-definition>
//
[OPENMP 4.0] Parsing/sema analysis for 'simdlen' clause in 'declare simd' construct. OpenMP 4.0 defines '#pragma omp declare simd' construct that may have associated 'simdlen' clause with constant positive expression as an argument: simdlen(<const_expr>) Patch adds parsin and semantic analysis for simdlen clause. llvm-svn: 265668
2016-04-07 20:45:37 +08:00
CachedTokens Toks;
[OPENMP5.0]Add basic support for declare variant directive. Added basic support for declare variant directive and its match clause with user context selector. llvm-svn: 371892
2019-09-14 04:18:17 +08:00
Toks.push_back(Tok);
ConsumeToken();
[OpenMP][NFC] Clang format ParseOpenMP ParseOpenMP.cpp was pretty much clang-formatted except a few minor locations. Let's make it a clang formatted file. Reviewed By: JonChesterfield Differential Revision: https://reviews.llvm.org/D90440
2020-10-30 07:44:28 +08:00
while (Tok.isNot(tok::annot_pragma_openmp_end)) {
[OPENMP 4.0] Support for 'uniform' clause in 'declare simd' directive. OpenMP 4.0 defines clause 'uniform' in 'declare simd' directive: 'uniform' '(' <argument-list> ')' The uniform clause declares one or more arguments to have an invariant value for all concurrent invocations of the function in the execution of a single SIMD loop. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266041
2016-04-12 13:28:34 +08:00
Toks.push_back(Tok);
ConsumeAnyToken();
}
Toks.push_back(Tok);
ConsumeAnyToken();
[OPENMP 4.0] Initial support for '#pragma omp declare simd' directive. Initial parsing/sema/serialization/deserialization support for '#pragma omp declare simd' directive. The 'declare simd' construct can be applied to a function to enable the creation of one or more versions that can process multiple arguments using SIMD instructions from a single invocation from a SIMD loop. If the function has any declarations, then the declare simd construct for any declaration that has one must be equivalent to the one specified for the definition. Otherwise, the result is unspecified. This pragma can be applied many times to the same declaration. Internally this pragma is represented as an attribute. But we need special processing for this pragma because it must be used before function declaration, this directive is applied to. Differential Revision: http://reviews.llvm.org/D10599 llvm-svn: 264853
2016-03-30 18:43:55 +08:00
DeclGroupPtrTy Ptr;
[OpenMP] Support OpenMP 5.1 attributes 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.
2021-07-12 18:51:19 +08:00
if (Tok.isOneOf(tok::annot_pragma_openmp, tok::annot_attr_openmp)) {
[OPENMP]Allow using of members in standalone declaration pragmas. If standalone OpenMP declaration pragma, like declare mapper or declare reduction, is declared in the class context, it may reference a member (data or function) in its internal expressions/statements. So, the parsing of such pragmas must be dalayed just like the parsing of the member initializers/definitions before the completion of the class declaration.
2020-01-08 02:39:18 +08:00
Ptr = ParseOpenMPDeclarativeDirectiveWithExtDecl(AS, Attrs, Delayed,
TagType, Tag);
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-24 03:53:05 +08:00
} else if (Tok.isNot(tok::r_brace) && !isEofOrEom()) {
[OPENMP 4.0] Initial support for '#pragma omp declare simd' directive. Initial parsing/sema/serialization/deserialization support for '#pragma omp declare simd' directive. The 'declare simd' construct can be applied to a function to enable the creation of one or more versions that can process multiple arguments using SIMD instructions from a single invocation from a SIMD loop. If the function has any declarations, then the declare simd construct for any declaration that has one must be equivalent to the one specified for the definition. Otherwise, the result is unspecified. This pragma can be applied many times to the same declaration. Internally this pragma is represented as an attribute. But we need special processing for this pragma because it must be used before function declaration, this directive is applied to. Differential Revision: http://reviews.llvm.org/D10599 llvm-svn: 264853
2016-03-30 18:43:55 +08:00
// Here we expect to see some function declaration.
if (AS == AS_none) {
assert(TagType == DeclSpec::TST_unspecified);
MaybeParseCXX11Attributes(Attrs);
ParsingDeclSpec PDS(*this);
Ptr = ParseExternalDeclaration(Attrs, &PDS);
} else {
Ptr =
ParseCXXClassMemberDeclarationWithPragmas(AS, Attrs, TagType, Tag);
}
}
if (!Ptr) {
[OPENMP5.0]Add basic support for declare variant directive. Added basic support for declare variant directive and its match clause with user context selector. llvm-svn: 371892
2019-09-14 04:18:17 +08:00
Diag(Loc, diag::err_omp_decl_in_declare_simd_variant)
<< (DKind == OMPD_declare_simd ? 0 : 1);
[OPENMP 4.0] Initial support for '#pragma omp declare simd' directive. Initial parsing/sema/serialization/deserialization support for '#pragma omp declare simd' directive. The 'declare simd' construct can be applied to a function to enable the creation of one or more versions that can process multiple arguments using SIMD instructions from a single invocation from a SIMD loop. If the function has any declarations, then the declare simd construct for any declaration that has one must be equivalent to the one specified for the definition. Otherwise, the result is unspecified. This pragma can be applied many times to the same declaration. Internally this pragma is represented as an attribute. But we need special processing for this pragma because it must be used before function declaration, this directive is applied to. Differential Revision: http://reviews.llvm.org/D10599 llvm-svn: 264853
2016-03-30 18:43:55 +08:00
return DeclGroupPtrTy();
}
[OPENMP5.0]Add basic support for declare variant directive. Added basic support for declare variant directive and its match clause with user context selector. llvm-svn: 371892
2019-09-14 04:18:17 +08:00
if (DKind == OMPD_declare_simd)
return ParseOMPDeclareSimdClauses(Ptr, Toks, Loc);
assert(DKind == OMPD_declare_variant &&
"Expected declare variant directive only");
[OPENMP5.0]Allow multiple context selectors in the context selector sets. According to OpenMP 5.0, context selector set might include several context selectors, separated with commas. Patch fixes this problem. llvm-svn: 372235
2019-09-19 00:24:31 +08:00
ParseOMPDeclareVariantClauses(Ptr, Toks, Loc);
return Ptr;
[OPENMP 4.0] Initial support for '#pragma omp declare simd' directive. Initial parsing/sema/serialization/deserialization support for '#pragma omp declare simd' directive. The 'declare simd' construct can be applied to a function to enable the creation of one or more versions that can process multiple arguments using SIMD instructions from a single invocation from a SIMD loop. If the function has any declarations, then the declare simd construct for any declaration that has one must be equivalent to the one specified for the definition. Otherwise, the result is unspecified. This pragma can be applied many times to the same declaration. Internally this pragma is represented as an attribute. But we need special processing for this pragma because it must be used before function declaration, this directive is applied to. Differential Revision: http://reviews.llvm.org/D10599 llvm-svn: 264853
2016-03-30 18:43:55 +08:00
}
[OpenMP] Overhaul `declare target` handling This patch fixes various issues with our prior `declare target` handling and extends it to support `omp begin declare target` as well. This started with PR49649 in mind, trying to provide a way for users to avoid the "ref" global use introduced for globals with internal linkage. From there it went down the rabbit hole, e.g., all variables, even `nohost` ones, were emitted into the device code so it was impossible to determine if "ref" was needed late in the game (based on the name only). To make it really useful, `begin declare target` was needed as it can carry the `device_type`. Not emitting variables eagerly had a ripple effect. Finally, the precedence of the (explicit) declare target list items needed to be taken into account, that meant we cannot just look for any declare target attribute to make a decision. This caused the handling of functions to require fixup as well. I tried to clean up things while I was at it, e.g., we should not "parse declarations and defintions" as part of OpenMP parsing, this will always break at some point. Instead, we keep track what region we are in and act on definitions and declarations instead, this is what we do for declare variant and other begin/end directives already. Highlights: - new diagnosis for restrictions specificed in the standard, - delayed emission of globals not mentioned in an explicit list of a declare target, - omission of `nohost` globals on the host and `host` globals on the device, - no explicit parsing of declarations in-between `omp [begin] declare variant` and the corresponding end anymore, regular parsing instead, - precedence for explicit mentions in `declare target` lists over implicit mentions in the declaration-definition-seq, and - `omp allocate` declarations will now replace an earlier emitted global, if necessary. --- Notes: The patch is larger than I hoped but it turns out that most changes do on their own lead to "inconsistent states", which seem less desirable overall. After working through this I feel the standard should remove the explicit declare target forms as the delayed emission is horrible. That said, while we delay things anyway, it seems to me we check too often for the current status even though that is often not sufficient to act upon. There seems to be a lot of duplication that can probably be trimmed down. Eagerly emitting some things seems pretty weak as an argument to keep so much logic around. --- Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D101030
2021-04-22 13:57:28 +08:00
case OMPD_begin_declare_target:
[OPENMP] Parsing and Sema support for 'omp declare target' directive Add parsing, sema analysis for 'declare target' construct for OpenMP 4.0 (4.5 support will be added in separate patch). The declare target directive specifies that variables, functions (C, C++ and Fortran), and subroutines (Fortran) are mapped to a device. The declare target directive is a declarative directive. In Clang declare target is implemented as implicit attribute for the declaration. The syntax of the declare target directive is as follows: #pragma omp declare target declarations-definition-seq #pragma omp end declare target Based on patch from Michael Wong http://reviews.llvm.org/D15321 llvm-svn: 265530
2016-04-06 19:38:59 +08:00
case OMPD_declare_target: {
SourceLocation DTLoc = ConsumeAnyToken();
[OpenMP] Overhaul `declare target` handling This patch fixes various issues with our prior `declare target` handling and extends it to support `omp begin declare target` as well. This started with PR49649 in mind, trying to provide a way for users to avoid the "ref" global use introduced for globals with internal linkage. From there it went down the rabbit hole, e.g., all variables, even `nohost` ones, were emitted into the device code so it was impossible to determine if "ref" was needed late in the game (based on the name only). To make it really useful, `begin declare target` was needed as it can carry the `device_type`. Not emitting variables eagerly had a ripple effect. Finally, the precedence of the (explicit) declare target list items needed to be taken into account, that meant we cannot just look for any declare target attribute to make a decision. This caused the handling of functions to require fixup as well. I tried to clean up things while I was at it, e.g., we should not "parse declarations and defintions" as part of OpenMP parsing, this will always break at some point. Instead, we keep track what region we are in and act on definitions and declarations instead, this is what we do for declare variant and other begin/end directives already. Highlights: - new diagnosis for restrictions specificed in the standard, - delayed emission of globals not mentioned in an explicit list of a declare target, - omission of `nohost` globals on the host and `host` globals on the device, - no explicit parsing of declarations in-between `omp [begin] declare variant` and the corresponding end anymore, regular parsing instead, - precedence for explicit mentions in `declare target` lists over implicit mentions in the declaration-definition-seq, and - `omp allocate` declarations will now replace an earlier emitted global, if necessary. --- Notes: The patch is larger than I hoped but it turns out that most changes do on their own lead to "inconsistent states", which seem less desirable overall. After working through this I feel the standard should remove the explicit declare target forms as the delayed emission is horrible. That said, while we delay things anyway, it seems to me we check too often for the current status even though that is often not sufficient to act upon. There seems to be a lot of duplication that can probably be trimmed down. Eagerly emitting some things seems pretty weak as an argument to keep so much logic around. --- Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D101030
2021-04-22 13:57:28 +08:00
bool HasClauses = Tok.isNot(tok::annot_pragma_openmp_end);
bool HasImplicitMappings =
DKind == OMPD_begin_declare_target || !HasClauses;
Sema::DeclareTargetContextInfo DTCI(DKind, DTLoc);
if (HasClauses)
ParseOMPDeclareTargetClauses(DTCI);
[OpenMP] Parse+Sema for '#pragma omp declare target' syntax version 4.5 Support OpenMP version 4.5 syntax for #pragma omp declare target. Syntax: #pragma omp declare target (extended-list) new-line or #pragma omp declare target clause[ [,] clause ... ] new-line Where clause is one of the following: to(extended-list) link(list) Differential Revision: http://reviews.llvm.org/D20011 llvm-svn: 268925
2016-05-09 22:59:13 +08:00
[OPENMP] Parsing and Sema support for 'omp declare target' directive Add parsing, sema analysis for 'declare target' construct for OpenMP 4.0 (4.5 support will be added in separate patch). The declare target directive specifies that variables, functions (C, C++ and Fortran), and subroutines (Fortran) are mapped to a device. The declare target directive is a declarative directive. In Clang declare target is implemented as implicit attribute for the declaration. The syntax of the declare target directive is as follows: #pragma omp declare target declarations-definition-seq #pragma omp end declare target Based on patch from Michael Wong http://reviews.llvm.org/D15321 llvm-svn: 265530
2016-04-06 19:38:59 +08:00
// Skip the last annot_pragma_openmp_end.
ConsumeAnyToken();
[OpenMP] Overhaul `declare target` handling This patch fixes various issues with our prior `declare target` handling and extends it to support `omp begin declare target` as well. This started with PR49649 in mind, trying to provide a way for users to avoid the "ref" global use introduced for globals with internal linkage. From there it went down the rabbit hole, e.g., all variables, even `nohost` ones, were emitted into the device code so it was impossible to determine if "ref" was needed late in the game (based on the name only). To make it really useful, `begin declare target` was needed as it can carry the `device_type`. Not emitting variables eagerly had a ripple effect. Finally, the precedence of the (explicit) declare target list items needed to be taken into account, that meant we cannot just look for any declare target attribute to make a decision. This caused the handling of functions to require fixup as well. I tried to clean up things while I was at it, e.g., we should not "parse declarations and defintions" as part of OpenMP parsing, this will always break at some point. Instead, we keep track what region we are in and act on definitions and declarations instead, this is what we do for declare variant and other begin/end directives already. Highlights: - new diagnosis for restrictions specificed in the standard, - delayed emission of globals not mentioned in an explicit list of a declare target, - omission of `nohost` globals on the host and `host` globals on the device, - no explicit parsing of declarations in-between `omp [begin] declare variant` and the corresponding end anymore, regular parsing instead, - precedence for explicit mentions in `declare target` lists over implicit mentions in the declaration-definition-seq, and - `omp allocate` declarations will now replace an earlier emitted global, if necessary. --- Notes: The patch is larger than I hoped but it turns out that most changes do on their own lead to "inconsistent states", which seem less desirable overall. After working through this I feel the standard should remove the explicit declare target forms as the delayed emission is horrible. That said, while we delay things anyway, it seems to me we check too often for the current status even though that is often not sufficient to act upon. There seems to be a lot of duplication that can probably be trimmed down. Eagerly emitting some things seems pretty weak as an argument to keep so much logic around. --- Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D101030
2021-04-22 13:57:28 +08:00
if (HasImplicitMappings) {
Actions.ActOnStartOpenMPDeclareTargetContext(DTCI);
return nullptr;
[OPENMP] Parsing and Sema support for 'omp declare target' directive Add parsing, sema analysis for 'declare target' construct for OpenMP 4.0 (4.5 support will be added in separate patch). The declare target directive specifies that variables, functions (C, C++ and Fortran), and subroutines (Fortran) are mapped to a device. The declare target directive is a declarative directive. In Clang declare target is implemented as implicit attribute for the declaration. The syntax of the declare target directive is as follows: #pragma omp declare target declarations-definition-seq #pragma omp end declare target Based on patch from Michael Wong http://reviews.llvm.org/D15321 llvm-svn: 265530
2016-04-06 19:38:59 +08:00
}
[OpenMP] Overhaul `declare target` handling This patch fixes various issues with our prior `declare target` handling and extends it to support `omp begin declare target` as well. This started with PR49649 in mind, trying to provide a way for users to avoid the "ref" global use introduced for globals with internal linkage. From there it went down the rabbit hole, e.g., all variables, even `nohost` ones, were emitted into the device code so it was impossible to determine if "ref" was needed late in the game (based on the name only). To make it really useful, `begin declare target` was needed as it can carry the `device_type`. Not emitting variables eagerly had a ripple effect. Finally, the precedence of the (explicit) declare target list items needed to be taken into account, that meant we cannot just look for any declare target attribute to make a decision. This caused the handling of functions to require fixup as well. I tried to clean up things while I was at it, e.g., we should not "parse declarations and defintions" as part of OpenMP parsing, this will always break at some point. Instead, we keep track what region we are in and act on definitions and declarations instead, this is what we do for declare variant and other begin/end directives already. Highlights: - new diagnosis for restrictions specificed in the standard, - delayed emission of globals not mentioned in an explicit list of a declare target, - omission of `nohost` globals on the host and `host` globals on the device, - no explicit parsing of declarations in-between `omp [begin] declare variant` and the corresponding end anymore, regular parsing instead, - precedence for explicit mentions in `declare target` lists over implicit mentions in the declaration-definition-seq, and - `omp allocate` declarations will now replace an earlier emitted global, if necessary. --- Notes: The patch is larger than I hoped but it turns out that most changes do on their own lead to "inconsistent states", which seem less desirable overall. After working through this I feel the standard should remove the explicit declare target forms as the delayed emission is horrible. That said, while we delay things anyway, it seems to me we check too often for the current status even though that is often not sufficient to act upon. There seems to be a lot of duplication that can probably be trimmed down. Eagerly emitting some things seems pretty weak as an argument to keep so much logic around. --- Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D101030
2021-04-22 13:57:28 +08:00
Actions.ActOnFinishedOpenMPDeclareTargetContext(DTCI);
llvm::SmallVector<Decl *, 4> Decls;
for (auto &It : DTCI.ExplicitlyMapped)
Decls.push_back(It.first);
[OPENMP] Codegen for ctor|dtor of declare target variables. When the declare target variables are emitted for the device, constructors|destructors for these variables must emitted and registered by the runtime in the offloading sections. llvm-svn: 328705
2018-03-28 22:28:54 +08:00
return Actions.BuildDeclaratorGroup(Decls);
[OPENMP] Parsing and Sema support for 'omp declare target' directive Add parsing, sema analysis for 'declare target' construct for OpenMP 4.0 (4.5 support will be added in separate patch). The declare target directive specifies that variables, functions (C, C++ and Fortran), and subroutines (Fortran) are mapped to a device. The declare target directive is a declarative directive. In Clang declare target is implemented as implicit attribute for the declaration. The syntax of the declare target directive is as follows: #pragma omp declare target declarations-definition-seq #pragma omp end declare target Based on patch from Michael Wong http://reviews.llvm.org/D15321 llvm-svn: 265530
2016-04-06 19:38:59 +08:00
}
[OpenMP] Overhaul `declare target` handling This patch fixes various issues with our prior `declare target` handling and extends it to support `omp begin declare target` as well. This started with PR49649 in mind, trying to provide a way for users to avoid the "ref" global use introduced for globals with internal linkage. From there it went down the rabbit hole, e.g., all variables, even `nohost` ones, were emitted into the device code so it was impossible to determine if "ref" was needed late in the game (based on the name only). To make it really useful, `begin declare target` was needed as it can carry the `device_type`. Not emitting variables eagerly had a ripple effect. Finally, the precedence of the (explicit) declare target list items needed to be taken into account, that meant we cannot just look for any declare target attribute to make a decision. This caused the handling of functions to require fixup as well. I tried to clean up things while I was at it, e.g., we should not "parse declarations and defintions" as part of OpenMP parsing, this will always break at some point. Instead, we keep track what region we are in and act on definitions and declarations instead, this is what we do for declare variant and other begin/end directives already. Highlights: - new diagnosis for restrictions specificed in the standard, - delayed emission of globals not mentioned in an explicit list of a declare target, - omission of `nohost` globals on the host and `host` globals on the device, - no explicit parsing of declarations in-between `omp [begin] declare variant` and the corresponding end anymore, regular parsing instead, - precedence for explicit mentions in `declare target` lists over implicit mentions in the declaration-definition-seq, and - `omp allocate` declarations will now replace an earlier emitted global, if necessary. --- Notes: The patch is larger than I hoped but it turns out that most changes do on their own lead to "inconsistent states", which seem less desirable overall. After working through this I feel the standard should remove the explicit declare target forms as the delayed emission is horrible. That said, while we delay things anyway, it seems to me we check too often for the current status even though that is often not sufficient to act upon. There seems to be a lot of duplication that can probably be trimmed down. Eagerly emitting some things seems pretty weak as an argument to keep so much logic around. --- Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D101030
2021-04-22 13:57:28 +08:00
case OMPD_end_declare_target: {
if (!Actions.isInOpenMPDeclareTargetContext()) {
Diag(Tok, diag::err_omp_unexpected_directive)
<< 1 << getOpenMPDirectiveName(DKind);
break;
}
const Sema::DeclareTargetContextInfo &DTCI =
Actions.ActOnOpenMPEndDeclareTargetDirective();
ParseOMPEndDeclareTargetDirective(DTCI.Kind, DKind, DTCI.Loc);
return nullptr;
}
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 14:34:35 +08:00
case OMPD_unknown:
Diag(Tok, diag::err_omp_unknown_directive);
break;
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
case OMPD_parallel:
[OPENMP] First changes for Parsing and Sema for 'omp simd' directive support llvm-svn: 202360
2014-02-27 16:29:12 +08:00
case OMPD_simd:
[OpenMP] Implement '#pragma omp tile', by Michael Kruse (@Meinersbur). The tile directive is in OpenMP's Technical Report 8 and foreseeably will be part of the upcoming OpenMP 5.1 standard. This implementation is based on an AST transformation providing a de-sugared loop nest. This makes it simple to forward the de-sugared transformation to loop associated directives taking the tiled loops. In contrast to other loop associated directives, the OMPTileDirective does not use CapturedStmts. Letting loop associated directives consume loops from different capture context would be difficult. A significant amount of code generation logic is taking place in the Sema class. Eventually, I would prefer if these would move into the CodeGen component such that we could make use of the OpenMPIRBuilder, together with flang. Only expressions converting between the language's iteration variable and the logical iteration space need to take place in the semantic analyzer: Getting the of iterations (e.g. the overload resolution of `std::distance`) and converting the logical iteration number to the iteration variable (e.g. overload resolution of `iteration + .omp.iv`). In clang, only CXXForRangeStmt is also represented by its de-sugared components. However, OpenMP loop are not defined as syntatic sugar. Starting with an AST-based approach allows us to gradually move generated AST statements into CodeGen, instead all at once. I would also like to refactor `checkOpenMPLoop` into its functionalities in a follow-up. In this patch it is used twice. Once for checking proper nesting and emitting diagnostics, and additionally for deriving the logical iteration space per-loop (instead of for the loop nest). Differential Revision: https://reviews.llvm.org/D76342
2021-02-13 03:26:59 +08:00
case OMPD_tile:
[OpenMP] Implement '#pragma omp unroll'. Implementation of the unroll directive introduced in OpenMP 5.1. Follows the approach from D76342 for the tile directive (i.e. AST-based, not using the OpenMPIRBuilder). Tries to use `llvm.loop.unroll.*` metadata where possible, but has to fall back to an AST representation of the outer loop if the partially unrolled generated loop is associated with another directive (because it needs to compute the number of iterations). Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D99459
2021-06-11 03:24:17 +08:00
case OMPD_unroll:
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
case OMPD_task:
[OPENMP] Initial parsing and sema analysis of 'taskyield' directive. llvm-svn: 213355
2014-07-18 15:47:19 +08:00
case OMPD_taskyield:
[OPENMP] Initial parsing and sema analysis for 'barrier' directive. llvm-svn: 213360
2014-07-18 17:11:51 +08:00
case OMPD_barrier:
[OPENMP] Initial parsing and sema analysis for 'taskwait' directive. llvm-svn: 213363
2014-07-18 18:17:07 +08:00
case OMPD_taskwait:
[OPENMP] Support for '#pragma omp taskgroup' directive. Added parsing, sema analysis and codegen for '#pragma omp taskgroup' directive (OpenMP 4.0). The code for directive is generated the following way: #pragma omp taskgroup <body> void __kmpc_taskgroup(<loc>, thread_id); <body> void __kmpc_end_taskgroup(<loc>, thread_id); llvm-svn: 240011
2015-06-18 20:14:09 +08:00
case OMPD_taskgroup:
[OPENMP] Initial parsing and sema analysis for 'flush' directive. llvm-svn: 213512
2014-07-21 19:26:11 +08:00
case OMPD_flush:
[OPENMP50]Add basic support for depobj construct. Added basic parsing/sema/serialization support for depobj directive.
2020-02-28 22:52:15 +08:00
case OMPD_depobj:
[OPENMP50]Initial support for scan directive. Addedi basic parsing/sema/serialization support for scan directive.
2020-03-20 19:03:01 +08:00
case OMPD_scan:
[OPENMP] Initial support for '#pragma omp for' (fixed incompatibility with MSVC). llvm-svn: 211140
2014-06-18 12:14:57 +08:00
case OMPD_for:
Parsing/Sema of directive omp for simd llvm-svn: 218029
2014-09-18 13:12:34 +08:00
case OMPD_for_simd:
[OPENMP] Initial support for 'sections' directive. llvm-svn: 211685
2014-06-25 19:44:49 +08:00
case OMPD_sections:
[OPENMP] Initial parsing and sema analysis for 'section' directive. llvm-svn: 211767
2014-06-26 16:21:58 +08:00
case OMPD_section:
[OPENMP] Initial parsing and sema analysis for 'single' directive. llvm-svn: 211774
2014-06-26 20:05:45 +08:00
case OMPD_single:
[OPENMP] Parsing/Sema analysis of directive 'master' llvm-svn: 213237
2014-07-17 16:54:58 +08:00
case OMPD_master:
[OPENMP] Initial parsing and sema analysis for 'ordered' directive. llvm-svn: 213616
2014-07-22 14:45:04 +08:00
case OMPD_ordered:
[OPENMP] Parsing/Sema of the OpenMP directive 'critical'. llvm-svn: 213510
2014-07-21 17:42:05 +08:00
case OMPD_critical:
[OPENMP] Added initial support for 'omp parallel for'. llvm-svn: 212453
2014-07-07 21:01:15 +08:00
case OMPD_parallel_for:
[OPENMP] Parsing/Sema of directive omp parallel for simd llvm-svn: 218299
2014-09-23 17:33:00 +08:00
case OMPD_parallel_for_simd:
[OPENMP] Parsing and sema analysis for 'omp parallel sections' directive. llvm-svn: 212516
2014-07-08 16:12:03 +08:00
case OMPD_parallel_sections:
[OpenMP50] Add parallel master construct Reviewers: ABataev, jdoerfert Reviewed By: ABataev Subscribers: rnk, jholewinski, guansong, arphaman, jfb, cfe-commits, sandoval, dreachem Tags: #clang Differential Revision: https://reviews.llvm.org/D70726
2019-12-06 02:43:48 +08:00
case OMPD_parallel_master:
[OPENMP] Initial parsing and sema analysis for 'atomic' directive. llvm-svn: 213639
2014-07-22 18:10:35 +08:00
case OMPD_atomic:
[OPENMP] Initial parsing/sema analysis of 'target' directive. llvm-svn: 218110
2014-09-19 16:19:49 +08:00
case OMPD_target:
[OPENMP] 'omp teams' directive basic support. Includes parsing and semantic analysis for 'omp teams' directive support from OpenMP 4.0. Adds additional analysis to 'omp target' directive with 'omp teams' directive. llvm-svn: 219385
2014-10-09 12:18:56 +08:00
case OMPD_teams:
[OPENMP 4.0] Initial support for 'omp cancellation point' construct. Add parsing and sema analysis for 'omp cancellation point' directive. llvm-svn: 241145
2015-07-01 14:57:41 +08:00
case OMPD_cancellation_point:
[OPENMP 4.0] Initial support for 'omp cancel' construct. Implemented parsing/sema analysis + (de)serialization. llvm-svn: 241253
2015-07-02 19:25:17 +08:00
case OMPD_cancel:
[OpenMP] Make target data directive generate unexpected directive diagnostic. llvm-svn: 242906
2015-07-23 00:02:46 +08:00
case OMPD_target_data:
[OpenMP] Parsing + sema for "target enter data" directive. Patch by Arpith Jacob. Thanks! llvm-svn: 258165
2016-01-20 03:15:56 +08:00
case OMPD_target_enter_data:
[OpenMP] Parsing + sema for "target exit data" directive. Patch by Arpith Jacob. Thanks! llvm-svn: 258177
2016-01-20 04:04:50 +08:00
case OMPD_target_exit_data:
[OpenMP] Parsing + sema for target parallel directive. Summary: This patch adds parsing + sema for the target parallel directive and its clauses along with testcases. Reviewers: ABataev Differential Revision: http://reviews.llvm.org/D16553 Rebased to current trunk and updated test cases. llvm-svn: 258832
2016-01-27 02:48:41 +08:00
case OMPD_target_parallel:
[OpenMP] Parsing + sema for target parallel for directive. Summary: This patch adds parsing + sema for the target parallel for directive along with testcases. Reviewers: ABataev Differential Revision: http://reviews.llvm.org/D16759 llvm-svn: 259654
2016-02-03 23:46:42 +08:00
case OMPD_target_parallel_for:
[OPENMP 4.5] Parsing/sema analysis for 'taskloop' directive. Adds initial parsing and semantic analysis for 'taskloop' directive. llvm-svn: 254367
2015-12-01 12:18:41 +08:00
case OMPD_taskloop:
[OPENMP 4.5] Parsing/sema support for 'omp taskloop simd' directive. OpenMP 4.5 adds directive 'taskloop simd'. Patch adds parsing/sema analysis for 'taskloop simd' directive and its clauses. llvm-svn: 254597
2015-12-03 17:40:15 +08:00
case OMPD_taskloop_simd:
[OPENMP50]Support for 'master taskloop' directive. Added full support for master taskloop directive. llvm-svn: 374437
2019-10-11 04:13:02 +08:00
case OMPD_master_taskloop:
[OPENMP50]Add support for master taskloop simd. Added trsing/semantics/codegen for combined construct master taskloop simd. llvm-svn: 375255
2019-10-19 00:47:35 +08:00
case OMPD_master_taskloop_simd:
[OPENMP50]Add support for 'parallel master taskloop' construct. Added parsing/sema/codegen support for 'parallel master taskloop' constructs. Some of the clauses, like 'grainsize', 'num_tasks', 'final' and 'priority' are not supported in full, only constant expressions can be used currently in these clauses. llvm-svn: 374791
2019-10-15 01:17:41 +08:00
case OMPD_parallel_master_taskloop:
[OPENMP50]Add support for parallel master taskloop simd directive. Added full support for parallel master taskloop simd directive.
2019-10-25 22:27:13 +08:00
case OMPD_parallel_master_taskloop_simd:
Add parse and sema of OpenMP distribute directive with all clauses except dist_schedule llvm-svn: 255498
2015-12-14 22:51:25 +08:00
case OMPD_distribute:
[OpenMP] Parsing and sema support for target update directive Summary: This patch is to add parsing and sema support for `target update` directive. Support for the `to` and `from` clauses will be added by a different patch. This patch also adds support for other clauses that are already implemented upstream and apply to `target update`, e.g. `device` and `if`. This patch is based on the original post by Kelvin Li. Reviewers: hfinkel, carlo.bertolli, kkwli0, arpith-jacob, ABataev Subscribers: caomhin, cfe-commits Differential Revision: http://reviews.llvm.org/D15944 llvm-svn: 270878
2016-05-27 01:30:50 +08:00
case OMPD_target_update:
Resubmission of http://reviews.llvm.org/D21564 after fixes. [OpenMP] Initial implementation of parse and sema for composite pragma 'distribute parallel for' This patch is an initial implementation for #distribute parallel for. The main differences that affect other pragmas are: The implementation of 'distribute parallel for' requires blocking of the associated loop, where blocks are "distributed" to different teams and iterations within each block are scheduled to parallel threads within each team. To implement blocking, sema creates two additional worksharing directive fields that are used to pass the team assigned block lower and upper bounds through the outlined function resulting from 'parallel'. In this way, scheduling for 'for' to threads can use those bounds. As a consequence of blocking, the stride of 'distribute' is not 1 but it is equal to the blocking size. This is returned by the runtime and sema prepares a DistIncrExpr variable to hold that value. As a consequence of blocking, the global upper bound (EnsureUpperBound) expression of the 'for' is not the original loop upper bound (e.g. in for(i = 0 ; i < N; i++) this is 'N') but it is the team-assigned block upper bound. Sema creates a new expression holding the calculation of the actual upper bound for 'for' as UB = min(UB, PrevUB), where UB is the loop upper bound, and PrevUB is the team-assigned block upper bound. llvm-svn: 273884
2016-06-27 22:55:37 +08:00
case OMPD_distribute_parallel_for:
[OpenMP] Sema and parse for 'distribute parallel for simd' Summary: This patch is an implementation of sema and parsing for the OpenMP composite pragma 'distribute parallel for simd'. Differential Revision: http://reviews.llvm.org/D21977 llvm-svn: 274530
2016-07-05 13:00:15 +08:00
case OMPD_distribute_parallel_for_simd:
[OpenMP] Sema and parsing for 'distribute simd' pragma Summary: This patch is an implementation of sema and parsing for the OpenMP composite pragma 'distribute simd'. Differential Revision: http://reviews.llvm.org/D22007 llvm-svn: 274604
2016-07-06 12:45:38 +08:00
case OMPD_distribute_simd:
[OpenMP] Sema and parsing for 'target parallel for simd' pragma This patch is to implement sema and parsing for 'target parallel for simd' pragma. Differential Revision: http://reviews.llvm.org/D22096 llvm-svn: 275365
2016-07-14 10:54:56 +08:00
case OMPD_target_parallel_for_simd:
[OpenMP] Sema and parsing for 'target simd' pragma This patch is to implement sema and parsing for 'target simd' pragma. Differential Revision: https://reviews.llvm.org/D22479 llvm-svn: 276203
2016-07-21 06:57:10 +08:00
case OMPD_target_simd:
[OpenMP] Sema and parsing for 'teams distribute' pragma This patch is to implement sema and parsing for 'teams distribute' pragma. Differential Revision: https://reviews.llvm.org/D23189 llvm-svn: 277818
2016-08-05 22:37:37 +08:00
case OMPD_teams_distribute:
Re-apply patch r279045. llvm-svn: 285066
2016-10-25 20:50:55 +08:00
case OMPD_teams_distribute_simd:
[OpenMP] Sema and parsing for 'teams distribute parallel for simd' pragma This patch is to implement sema and parsing for 'teams distribute parallel for simd' pragma. Differential Revision: https://reviews.llvm.org/D27084 llvm-svn: 288294
2016-12-01 07:51:03 +08:00
case OMPD_teams_distribute_parallel_for_simd:
[OpenMP] Sema and parsing for 'teams distribute parallel for' pragma This patch is to implement sema and parsing for 'teams distribute parallel for' pragma. Differential Revision: https://reviews.llvm.org/D27345 llvm-svn: 289179
2016-12-09 11:24:30 +08:00
case OMPD_teams_distribute_parallel_for:
[OpenMP] Sema and parsing for 'target teams' pragma This patch is to implement sema and parsing for 'target teams' pragma. Differential Revision: https://reviews.llvm.org/D27818 llvm-svn: 290038
2016-12-17 13:48:59 +08:00
case OMPD_target_teams:
[OpenMP] Sema and parsing for 'target teams distribute' pragma This patch is to implement sema and parsing for 'target teams distribute' pragma. Differential Revision: https://reviews.llvm.org/D28015 llvm-svn: 290508
2016-12-25 12:52:54 +08:00
case OMPD_target_teams_distribute:
[OpenMP] Sema and parsing for 'target teams distribute parallel for’ pragma This patch is to implement sema and parsing for 'target teams distribute parallel for’ pragma. Differential Revision: https://reviews.llvm.org/D28160 llvm-svn: 290725
2016-12-30 06:16:30 +08:00
case OMPD_target_teams_distribute_parallel_for:
[OpenMP] Sema and parsing for 'target teams distribute parallel for simd’ pragma This patch is to implement sema and parsing for 'target teams distribute parallel for simd’ pragma. Differential Revision: https://reviews.llvm.org/D28202 llvm-svn: 290862
2017-01-03 13:23:48 +08:00
case OMPD_target_teams_distribute_parallel_for_simd:
[OpenMP] Sema and parsing for 'target teams distribute simd’ pragma This patch is to implement sema and parsing for 'target teams distribute simd’ pragma. Differential Revision: https://reviews.llvm.org/D28252 llvm-svn: 291579
2017-01-11 02:08:18 +08:00
case OMPD_target_teams_distribute_simd:
[OPENMP51]Initial support for the dispatch directive. Added basic parsing/sema/serialization support for dispatch directive. Differential Revision: https://reviews.llvm.org/D99537
2021-03-23 09:13:29 +08:00
case OMPD_dispatch:
[OpenMP51] Initial support for masked directive and filter clause Adds basic parsing/sema/serialization support for the #pragma omp masked directive. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D99995
2021-04-10 03:00:36 +08:00
case OMPD_masked:
OpenMP 5.0 metadirective This patch supports OpenMP 5.0 metadirective features. It is implemented keeping the OpenMP 5.1 features like dynamic user condition in mind. A new function, getBestWhenMatchForContext, is defined in llvm/Frontend/OpenMP/OMPContext.h Currently this function return the index of the when clause with the highest score from the ones applicable in the Context. But this function is declared with an array which can be used in OpenMP 5.1 implementation to select all the valid when clauses which can be resolved in runtime. Currently this array is set to null by default and its implementation is left for future. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D91944
2021-09-18 05:03:01 +08:00
case OMPD_metadirective:
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 14:34:35 +08:00
Diag(Tok, diag::err_omp_unexpected_directive)
[OPENMP] Fix parsing of the directives with inner directives. The parsing may lead to compiler hanging because of the incorrect processing of inner OpenMP pragmas. llvm-svn: 325369
2018-02-17 02:36:44 +08:00
<< 1 << getOpenMPDirectiveName(DKind);
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 14:34:35 +08:00
break;
[flang][openmp] Use common Directive and Clause enum from llvm/Frontend Summary: This patch is removing the custom enumeration for OpenMP Directives and Clauses and replace them with the newly tablegen generated one from llvm/Frontend. This is a first patch and some will follow to share the same infrastructure where possible. The next patch should use the clauses allowance defined in the tablegen file. Reviewers: jdoerfert, DavidTruby, sscalpone, kiranchandramohan, ichoyjx Reviewed By: DavidTruby, ichoyjx Subscribers: jholewinski, cfe-commits, dblaikie, MaskRay, ymandel, ichoyjx, mgorny, yaxunl, guansong, jfb, sstefan1, aaron.ballman, llvm-commits Tags: #llvm, #flang, #clang Differential Revision: https://reviews.llvm.org/D82906
2020-07-02 08:57:11 +08:00
default:
break;
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 14:34:35 +08:00
}
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
while (Tok.isNot(tok::annot_pragma_openmp_end))
ConsumeAnyToken();
ConsumeAnyToken();
OpaquePtr: Use nullptr construction for DeclGroupPtrTy OpaquePtr typedef llvm-svn: 257956
2016-01-16 07:43:25 +08:00
return nullptr;
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 14:34:35 +08:00
}
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Parsing of declarative or executable OpenMP directives.
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
///
/// threadprivate-directive:
/// annot_pragma_openmp 'threadprivate' simple-variable-list
/// annot_pragma_openmp_end
///
[OPENMP 5.0]Add initial support for 'allocate' directive. Added parsing/sema analysis/serialization/deserialization support for 'allocate' directive. llvm-svn: 355614
2019-03-08 01:54:44 +08:00
/// allocate-directive:
/// annot_pragma_openmp 'allocate' simple-variable-list
/// annot_pragma_openmp_end
///
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
/// declare-reduction-directive:
/// annot_pragma_openmp 'declare' 'reduction' '(' <reduction_id> ':'
/// <type> {',' <type>} ':' <expression> ')' ['initializer' '('
/// ('omp_priv' '=' <expression>|<function_call>) ')']
/// annot_pragma_openmp_end
///
[OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive. This patch implements parsing and sema for "omp declare mapper" directive. User defined mapper, i.e., declare mapper directive, is a new feature in OpenMP 5.0. It is introduced to extend existing map clauses for the purpose of simplifying the copy of complex data structures between host and device (i.e., deep copy). An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(struct S s) map(s, s.d[0:s.len]) // Memory region that d points to is also mapped using this mapper. Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D56326 llvm-svn: 352906
2019-02-02 04:25:04 +08:00
/// declare-mapper-directive:
/// annot_pragma_openmp 'declare' 'mapper' '(' [<mapper-identifer> ':']
/// <type> <var> ')' [<clause>[[,] <clause>] ... ]
/// annot_pragma_openmp_end
///
[OPENMP] Initial support for 'sections' directive. llvm-svn: 211685
2014-06-25 19:44:49 +08:00
/// executable-directive:
[OPENMP] Initial parsing and sema analysis for 'single' directive. llvm-svn: 211774
2014-06-26 20:05:45 +08:00
/// annot_pragma_openmp 'parallel' | 'simd' | 'for' | 'sections' |
[OPENMP] Parsing/Sema of the OpenMP directive 'critical'. llvm-svn: 213510
2014-07-21 17:42:05 +08:00
/// 'section' | 'single' | 'master' | 'critical' [ '(' <name> ')' ] |
[OpenMP50] Add parallel master construct Reviewers: ABataev, jdoerfert Reviewed By: ABataev Subscribers: rnk, jholewinski, guansong, arphaman, jfb, cfe-commits, sandoval, dreachem Tags: #clang Differential Revision: https://reviews.llvm.org/D70726
2019-12-06 02:43:48 +08:00
/// 'parallel for' | 'parallel sections' | 'parallel master' | 'task' |
/// 'taskyield' | 'barrier' | 'taskwait' | 'flush' | 'ordered' |
/// 'atomic' | 'for simd' | 'parallel for simd' | 'target' | 'target
/// data' | 'taskgroup' | 'teams' | 'taskloop' | 'taskloop simd' |
/// 'master taskloop' | 'master taskloop simd' | 'parallel master
/// taskloop' | 'parallel master taskloop simd' | 'distribute' | 'target
/// enter data' | 'target exit data' | 'target parallel' | 'target
/// parallel for' | 'target update' | 'distribute parallel for' |
/// 'distribute paralle for simd' | 'distribute simd' | 'target parallel
/// for simd' | 'target simd' | 'teams distribute' | 'teams distribute
/// simd' | 'teams distribute parallel for simd' | 'teams distribute
/// parallel for' | 'target teams' | 'target teams distribute' | 'target
/// teams distribute parallel for' | 'target teams distribute parallel
[OpenMP51] Initial support for masked directive and filter clause Adds basic parsing/sema/serialization support for the #pragma omp masked directive. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D99995
2021-04-10 03:00:36 +08:00
/// for simd' | 'target teams distribute simd' | 'masked' {clause}
[OPENMP50]Add support for parallel master taskloop simd directive. Added full support for parallel master taskloop simd directive.
2019-10-25 22:27:13 +08:00
/// annot_pragma_openmp_end
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
///
PR40642: Fix determination of whether the final statement of a statement expression is a discarded-value expression. Summary: We used to get this wrong in three ways: 1) During parsing, an expression-statement followed by the }) ending a statement expression was always treated as producing the value of the statement expression. That's wrong for ({ if (1) expr; }) 2) During template instantiation, various kinds of statement (most statements not appearing directly in a compound-statement) were not treated as discarded-value expressions, resulting in missing volatile loads (etc). 3) In all contexts, an expression-statement with attributes was not treated as producing the value of the statement expression, eg ({ [[attr]] expr; }). Also fix incorrect enforcement of OpenMP rule that directives can "only be placed in the program at a position where ignoring or deleting the directive would result in a program with correct syntax". In particular, a label (be it goto, case, or default) should not affect whether directives are permitted. Reviewers: aaron.ballman, rjmccall Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57984 llvm-svn: 354090
2019-02-15 08:27:53 +08:00
StmtResult
Parser::ParseOpenMPDeclarativeOrExecutableDirective(ParsedStmtContext StmtCtx) {
OpenMP 5.0 metadirective This patch supports OpenMP 5.0 metadirective features. It is implemented keeping the OpenMP 5.1 features like dynamic user condition in mind. A new function, getBestWhenMatchForContext, is defined in llvm/Frontend/OpenMP/OMPContext.h Currently this function return the index of the when clause with the highest score from the ones applicable in the Context. But this function is declared with an array which can be used in OpenMP 5.1 implementation to select all the valid when clauses which can be resolved in runtime. Currently this array is set to null by default and its implementation is left for future. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D91944
2021-09-18 05:03:01 +08:00
static bool ReadDirectiveWithinMetadirective = false;
if (!ReadDirectiveWithinMetadirective)
assert(Tok.isOneOf(tok::annot_pragma_openmp, tok::annot_attr_openmp) &&
"Not an OpenMP directive!");
[OPENMP]Fix skipping of functions body. When parsing the code with OpenMP and the function's body must be skipped, need to skip also OpenMP annotation tokens. Otherwise the counters for braces/parens are unbalanced and parsing fails.
2019-12-14 05:05:30 +08:00
ParsingOpenMPDirectiveRAII DirScope(*this);
Replaced bool parameters in SkipUntil function with single bit-based parameter. llvm-svn: 194994
2013-11-18 16:17:37 +08:00
ParenBraceBracketBalancer BalancerRAIIObj(*this);
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
SmallVector<OMPClause *, 5> Clauses;
[OpenMP][NFCI] Move OpenMP clause information to `lib/Frontend/OpenMP` This is a cleanup and normalization patch that also enables reuse with Flang later on. A follow up will clean up and move the directive -> clauses mapping. Reviewed By: fghanim Differential Revision: https://reviews.llvm.org/D77112
2020-03-31 08:58:40 +08:00
SmallVector<llvm::PointerIntPair<OMPClause *, 1, bool>,
[openmp] Base of tablegen generated OpenMP common declaration Summary: As discussed previously when landing patch for OpenMP in Flang, the idea is to share common part of the OpenMP declaration between the different Frontend. While doing this it was thought that moving to tablegen instead of Macros will also give a cleaner and more powerful way of generating these declaration. This first part of a future series of patches is setting up the base .td file for DirectiveLanguage as well as the OpenMP version of it. The base file is meant to be used by other directive language such as OpenACC. In this first patch, the Directive and Clause enums are generated with tablegen instead of the macros on OMPConstants.h. The next pacth will extend this to other enum and move the Flang frontend to use it. Reviewers: jdoerfert, DavidTruby, fghanim, ABataev, jdenny, hfinkel, jhuber6, kiranchandramohan, kiranktp Reviewed By: jdoerfert, jdenny Subscribers: arphaman, martong, cfe-commits, mgorny, yaxunl, hiraditya, guansong, jfb, sstefan1, aaron.ballman, llvm-commits Tags: #llvm, #openmp, #clang Differential Revision: https://reviews.llvm.org/D81736
2020-06-23 21:29:50 +08:00
llvm::omp::Clause_enumSize + 1>
FirstClauses(llvm::omp::Clause_enumSize + 1);
Place implictly declared functions at block scope Such implicitly declared functions behave as if the enclosing block contained the declaration extern int name() (C90, 6.3.3.2 Function calls), thus their names should have block scope (C90, 6.1.2.1 Scope of identifiers). This patch fixes https://bugs.llvm.org/show_bug.cgi?id=33224 Differential Revision: https://reviews.llvm.org/D33676 llvm-svn: 310616
2017-08-10 23:43:06 +08:00
unsigned ScopeFlags = Scope::FnScope | Scope::DeclScope |
Scope::CompoundStmtScope | Scope::OpenMPDirectiveScope;
OpenMP 5.0 metadirective This patch supports OpenMP 5.0 metadirective features. It is implemented keeping the OpenMP 5.1 features like dynamic user condition in mind. A new function, getBestWhenMatchForContext, is defined in llvm/Frontend/OpenMP/OMPContext.h Currently this function return the index of the when clause with the highest score from the ones applicable in the Context. But this function is declared with an array which can be used in OpenMP 5.1 implementation to select all the valid when clauses which can be resolved in runtime. Currently this array is set to null by default and its implementation is left for future. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D91944
2021-09-18 05:03:01 +08:00
SourceLocation Loc = ReadDirectiveWithinMetadirective
? Tok.getLocation()
: ConsumeAnnotationToken(),
EndLoc;
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-24 03:53:05 +08:00
OpenMPDirectiveKind DKind = parseOpenMPDirectiveKind(*this);
OpenMP 5.0 metadirective This patch supports OpenMP 5.0 metadirective features. It is implemented keeping the OpenMP 5.1 features like dynamic user condition in mind. A new function, getBestWhenMatchForContext, is defined in llvm/Frontend/OpenMP/OMPContext.h Currently this function return the index of the when clause with the highest score from the ones applicable in the Context. But this function is declared with an array which can be used in OpenMP 5.1 implementation to select all the valid when clauses which can be resolved in runtime. Currently this array is set to null by default and its implementation is left for future. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D91944
2021-09-18 05:03:01 +08:00
if (ReadDirectiveWithinMetadirective && DKind == OMPD_unknown) {
Diag(Tok, diag::err_omp_unknown_directive);
return StmtError();
}
[OPENMP 4.0] Initial support for 'omp cancellation point' construct. Add parsing and sema analysis for 'omp cancellation point' directive. llvm-svn: 241145
2015-07-01 14:57:41 +08:00
OpenMPDirectiveKind CancelRegion = OMPD_unknown;
OpenMP: Data-sharing attributes analysis and clause 'shared' (fixed test threadprivate_messages.cpp) llvm-svn: 190183
2013-09-07 02:03:48 +08:00
// Name of critical directive.
DeclarationNameInfo DirName;
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
StmtResult Directive = StmtError();
[OPENMP] Initial parsing and sema analysis of 'taskyield' directive. llvm-svn: 213355
2014-07-18 15:47:19 +08:00
bool HasAssociatedStatement = true;
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
switch (DKind) {
OpenMP 5.0 metadirective This patch supports OpenMP 5.0 metadirective features. It is implemented keeping the OpenMP 5.1 features like dynamic user condition in mind. A new function, getBestWhenMatchForContext, is defined in llvm/Frontend/OpenMP/OMPContext.h Currently this function return the index of the when clause with the highest score from the ones applicable in the Context. But this function is declared with an array which can be used in OpenMP 5.1 implementation to select all the valid when clauses which can be resolved in runtime. Currently this array is set to null by default and its implementation is left for future. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D91944
2021-09-18 05:03:01 +08:00
case OMPD_metadirective: {
ConsumeToken();
SmallVector<VariantMatchInfo, 4> VMIs;
// First iteration of parsing all clauses of metadirective.
// This iteration only parses and collects all context selector ignoring the
// associated directives.
TentativeParsingAction TPA(*this);
ASTContext &ASTContext = Actions.getASTContext();
BalancedDelimiterTracker T(*this, tok::l_paren,
tok::annot_pragma_openmp_end);
while (Tok.isNot(tok::annot_pragma_openmp_end)) {
OpenMPClauseKind CKind = Tok.isAnnotation()
? OMPC_unknown
: getOpenMPClauseKind(PP.getSpelling(Tok));
SourceLocation Loc = ConsumeToken();
// Parse '('.
if (T.expectAndConsume(diag::err_expected_lparen_after,
getOpenMPClauseName(CKind).data()))
return Directive;
OMPTraitInfo &TI = Actions.getASTContext().getNewOMPTraitInfo();
if (CKind == OMPC_when) {
// parse and get OMPTraitInfo to pass to the When clause
parseOMPContextSelectors(Loc, TI);
if (TI.Sets.size() == 0) {
Diag(Tok, diag::err_omp_expected_context_selector) << "when clause";
TPA.Commit();
return Directive;
}
// Parse ':'
if (Tok.is(tok::colon))
ConsumeAnyToken();
else {
Diag(Tok, diag::err_omp_expected_colon) << "when clause";
TPA.Commit();
return Directive;
}
}
// Skip Directive for now. We will parse directive in the second iteration
int paren = 0;
while (Tok.isNot(tok::r_paren) || paren != 0) {
if (Tok.is(tok::l_paren))
paren++;
if (Tok.is(tok::r_paren))
paren--;
if (Tok.is(tok::annot_pragma_openmp_end)) {
Diag(Tok, diag::err_omp_expected_punc)
<< getOpenMPClauseName(CKind) << 0;
TPA.Commit();
return Directive;
}
ConsumeAnyToken();
}
// Parse ')'
if (Tok.is(tok::r_paren))
T.consumeClose();
VariantMatchInfo VMI;
TI.getAsVariantMatchInfo(ASTContext, VMI);
VMIs.push_back(VMI);
}
TPA.Revert();
// End of the first iteration. Parser is reset to the start of metadirective
TargetOMPContext OMPCtx(ASTContext, /* DiagUnknownTrait */ nullptr,
/* CurrentFunctionDecl */ nullptr,
ArrayRef<llvm::omp::TraitProperty>());
// A single match is returned for OpenMP 5.0
int BestIdx = getBestVariantMatchForContext(VMIs, OMPCtx);
int Idx = 0;
// In OpenMP 5.0 metadirective is either replaced by another directive or
// ignored.
// TODO: In OpenMP 5.1 generate multiple directives based upon the matches
// found by getBestWhenMatchForContext.
while (Tok.isNot(tok::annot_pragma_openmp_end)) {
// OpenMP 5.0 implementation - Skip to the best index found.
if (Idx++ != BestIdx) {
ConsumeToken(); // Consume clause name
T.consumeOpen(); // Consume '('
int paren = 0;
// Skip everything inside the clause
while (Tok.isNot(tok::r_paren) || paren != 0) {
if (Tok.is(tok::l_paren))
paren++;
if (Tok.is(tok::r_paren))
paren--;
ConsumeAnyToken();
}
// Parse ')'
if (Tok.is(tok::r_paren))
T.consumeClose();
continue;
}
OpenMPClauseKind CKind = Tok.isAnnotation()
? OMPC_unknown
: getOpenMPClauseKind(PP.getSpelling(Tok));
SourceLocation Loc = ConsumeToken();
// Parse '('.
T.consumeOpen();
// Skip ContextSelectors for when clause
if (CKind == OMPC_when) {
OMPTraitInfo &TI = Actions.getASTContext().getNewOMPTraitInfo();
// parse and skip the ContextSelectors
parseOMPContextSelectors(Loc, TI);
// Parse ':'
ConsumeAnyToken();
}
// If no directive is passed, skip in OpenMP 5.0.
// TODO: Generate nothing directive from OpenMP 5.1.
if (Tok.is(tok::r_paren)) {
SkipUntil(tok::annot_pragma_openmp_end);
break;
}
// Parse Directive
ReadDirectiveWithinMetadirective = true;
Directive = ParseOpenMPDeclarativeOrExecutableDirective(StmtCtx);
ReadDirectiveWithinMetadirective = false;
break;
}
break;
}
[OpenMP] Parse+Sema for '#pragma omp declare target' syntax version 4.5 Support OpenMP version 4.5 syntax for #pragma omp declare target. Syntax: #pragma omp declare target (extended-list) new-line or #pragma omp declare target clause[ [,] clause ... ] new-line Where clause is one of the following: to(extended-list) link(list) Differential Revision: http://reviews.llvm.org/D20011 llvm-svn: 268925
2016-05-09 22:59:13 +08:00
case OMPD_threadprivate: {
PR40642: Fix determination of whether the final statement of a statement expression is a discarded-value expression. Summary: We used to get this wrong in three ways: 1) During parsing, an expression-statement followed by the }) ending a statement expression was always treated as producing the value of the statement expression. That's wrong for ({ if (1) expr; }) 2) During template instantiation, various kinds of statement (most statements not appearing directly in a compound-statement) were not treated as discarded-value expressions, resulting in missing volatile loads (etc). 3) In all contexts, an expression-statement with attributes was not treated as producing the value of the statement expression, eg ({ [[attr]] expr; }). Also fix incorrect enforcement of OpenMP rule that directives can "only be placed in the program at a position where ignoring or deleting the directive would result in a program with correct syntax". In particular, a label (be it goto, case, or default) should not affect whether directives are permitted. Reviewers: aaron.ballman, rjmccall Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57984 llvm-svn: 354090
2019-02-15 08:27:53 +08:00
// FIXME: Should this be permitted in C++?
if ((StmtCtx & ParsedStmtContext::AllowDeclarationsInC) ==
ParsedStmtContext()) {
[OPENMP] Fix for declarative/standalone directives use. Fixes processing of declarative directives and standalone executable directives. Declarative directives should not be allowed as an immediate statements and standalone executable directives are allowed to be used in case-stmt constructs. llvm-svn: 257586
2016-01-13 19:18:54 +08:00
Diag(Tok, diag::err_omp_immediate_directive)
<< getOpenMPDirectiveName(DKind) << 0;
}
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
ConsumeToken();
[OPENMP 5.0]Add initial support for 'allocate' directive. Added parsing/sema analysis/serialization/deserialization support for 'allocate' directive. llvm-svn: 355614
2019-03-08 01:54:44 +08:00
DeclDirectiveListParserHelper Helper(this, DKind);
if (!ParseOpenMPSimpleVarList(DKind, Helper,
/*AllowScopeSpecifier=*/false)) {
[OpenMP][NFC] Outline common functionality (skipUntilPragmaOpenMPEnd) The same code was repeated multiple times, we put it in a function now.
2020-02-22 03:48:56 +08:00
skipUntilPragmaOpenMPEnd(DKind);
[OpenMP] Parse+Sema for '#pragma omp declare target' syntax version 4.5 Support OpenMP version 4.5 syntax for #pragma omp declare target. Syntax: #pragma omp declare target (extended-list) new-line or #pragma omp declare target clause[ [,] clause ... ] new-line Where clause is one of the following: to(extended-list) link(list) Differential Revision: http://reviews.llvm.org/D20011 llvm-svn: 268925
2016-05-09 22:59:13 +08:00
DeclGroupPtrTy Res = Actions.ActOnOpenMPThreadprivateDirective(
Loc, Helper.getIdentifiers());
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
Directive = Actions.ActOnDeclStmt(Res, Loc, Tok.getLocation());
}
Revert "[OPENMP] Fix for parsing OpenMP directives with extra braces, brackets and parens" These parser changes were redundant. The same or better recovery can be achieved with a one-line fix to SkipUntil() due to land in the next commit. This reverts commit r197553. llvm-svn: 197597
2013-12-19 03:10:49 +08:00
SkipUntil(tok::annot_pragma_openmp_end);
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
break;
[OpenMP] Parse+Sema for '#pragma omp declare target' syntax version 4.5 Support OpenMP version 4.5 syntax for #pragma omp declare target. Syntax: #pragma omp declare target (extended-list) new-line or #pragma omp declare target clause[ [,] clause ... ] new-line Where clause is one of the following: to(extended-list) link(list) Differential Revision: http://reviews.llvm.org/D20011 llvm-svn: 268925
2016-05-09 22:59:13 +08:00
}
[OPENMP 5.0]Add initial support for 'allocate' directive. Added parsing/sema analysis/serialization/deserialization support for 'allocate' directive. llvm-svn: 355614
2019-03-08 01:54:44 +08:00
case OMPD_allocate: {
// FIXME: Should this be permitted in C++?
if ((StmtCtx & ParsedStmtContext::AllowDeclarationsInC) ==
ParsedStmtContext()) {
Diag(Tok, diag::err_omp_immediate_directive)
<< getOpenMPDirectiveName(DKind) << 0;
}
ConsumeToken();
DeclDirectiveListParserHelper Helper(this, DKind);
if (!ParseOpenMPSimpleVarList(DKind, Helper,
/*AllowScopeSpecifier=*/false)) {
[OPENMP 5.0]Initial support for 'allocator' clause. Added parsing/sema analysis/serialization/deserialization for the 'allocator' clause of the 'allocate' directive. llvm-svn: 355952
2019-03-13 02:52:33 +08:00
SmallVector<OMPClause *, 1> Clauses;
[OPENMP 5.0]Add initial support for 'allocate' directive. Added parsing/sema analysis/serialization/deserialization support for 'allocate' directive. llvm-svn: 355614
2019-03-08 01:54:44 +08:00
if (Tok.isNot(tok::annot_pragma_openmp_end)) {
[OPENMP 5.0]Initial support for 'allocator' clause. Added parsing/sema analysis/serialization/deserialization for the 'allocator' clause of the 'allocate' directive. llvm-svn: 355952
2019-03-13 02:52:33 +08:00
SmallVector<llvm::PointerIntPair<OMPClause *, 1, bool>,
[openmp] Base of tablegen generated OpenMP common declaration Summary: As discussed previously when landing patch for OpenMP in Flang, the idea is to share common part of the OpenMP declaration between the different Frontend. While doing this it was thought that moving to tablegen instead of Macros will also give a cleaner and more powerful way of generating these declaration. This first part of a future series of patches is setting up the base .td file for DirectiveLanguage as well as the OpenMP version of it. The base file is meant to be used by other directive language such as OpenACC. In this first patch, the Directive and Clause enums are generated with tablegen instead of the macros on OMPConstants.h. The next pacth will extend this to other enum and move the Flang frontend to use it. Reviewers: jdoerfert, DavidTruby, fghanim, ABataev, jdenny, hfinkel, jhuber6, kiranchandramohan, kiranktp Reviewed By: jdoerfert, jdenny Subscribers: arphaman, martong, cfe-commits, mgorny, yaxunl, hiraditya, guansong, jfb, sstefan1, aaron.ballman, llvm-commits Tags: #llvm, #openmp, #clang Differential Revision: https://reviews.llvm.org/D81736
2020-06-23 21:29:50 +08:00
llvm::omp::Clause_enumSize + 1>
FirstClauses(llvm::omp::Clause_enumSize + 1);
[OPENMP 5.0]Initial support for 'allocator' clause. Added parsing/sema analysis/serialization/deserialization for the 'allocator' clause of the 'allocate' directive. llvm-svn: 355952
2019-03-13 02:52:33 +08:00
while (Tok.isNot(tok::annot_pragma_openmp_end)) {
OpenMPClauseKind CKind =
Tok.isAnnotation() ? OMPC_unknown
: getOpenMPClauseKind(PP.getSpelling(Tok));
Actions.StartOpenMPClause(CKind);
[OpenMP][NFCI] Move OpenMP clause information to `lib/Frontend/OpenMP` This is a cleanup and normalization patch that also enables reuse with Flang later on. A follow up will clean up and move the directive -> clauses mapping. Reviewed By: fghanim Differential Revision: https://reviews.llvm.org/D77112
2020-03-31 08:58:40 +08:00
OMPClause *Clause = ParseOpenMPClause(
OMPD_allocate, CKind, !FirstClauses[unsigned(CKind)].getInt());
[OPENMP 5.0]Initial support for 'allocator' clause. Added parsing/sema analysis/serialization/deserialization for the 'allocator' clause of the 'allocate' directive. llvm-svn: 355952
2019-03-13 02:52:33 +08:00
SkipUntil(tok::comma, tok::identifier, tok::annot_pragma_openmp_end,
StopBeforeMatch);
[OpenMP][NFCI] Move OpenMP clause information to `lib/Frontend/OpenMP` This is a cleanup and normalization patch that also enables reuse with Flang later on. A follow up will clean up and move the directive -> clauses mapping. Reviewed By: fghanim Differential Revision: https://reviews.llvm.org/D77112
2020-03-31 08:58:40 +08:00
FirstClauses[unsigned(CKind)].setInt(true);
[OPENMP 5.0]Initial support for 'allocator' clause. Added parsing/sema analysis/serialization/deserialization for the 'allocator' clause of the 'allocate' directive. llvm-svn: 355952
2019-03-13 02:52:33 +08:00
if (Clause != nullptr)
Clauses.push_back(Clause);
if (Tok.is(tok::annot_pragma_openmp_end)) {
Actions.EndOpenMPClause();
break;
}
// Skip ',' if any.
if (Tok.is(tok::comma))
ConsumeToken();
Actions.EndOpenMPClause();
}
[OpenMP][NFC] Outline common functionality (skipUntilPragmaOpenMPEnd) The same code was repeated multiple times, we put it in a function now.
2020-02-22 03:48:56 +08:00
skipUntilPragmaOpenMPEnd(DKind);
[OPENMP 5.0]Add initial support for 'allocate' directive. Added parsing/sema analysis/serialization/deserialization support for 'allocate' directive. llvm-svn: 355614
2019-03-08 01:54:44 +08:00
}
[OPENMP 5.0]Initial support for 'allocator' clause. Added parsing/sema analysis/serialization/deserialization for the 'allocator' clause of the 'allocate' directive. llvm-svn: 355952
2019-03-13 02:52:33 +08:00
DeclGroupPtrTy Res = Actions.ActOnOpenMPAllocateDirective(
Loc, Helper.getIdentifiers(), Clauses);
[OPENMP 5.0]Add initial support for 'allocate' directive. Added parsing/sema analysis/serialization/deserialization support for 'allocate' directive. llvm-svn: 355614
2019-03-08 01:54:44 +08:00
Directive = Actions.ActOnDeclStmt(Res, Loc, Tok.getLocation());
}
SkipUntil(tok::annot_pragma_openmp_end);
break;
}
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
case OMPD_declare_reduction:
ConsumeToken();
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-24 03:53:05 +08:00
if (DeclGroupPtrTy Res =
ParseOpenMPDeclareReductionDirective(/*AS=*/AS_none)) {
[OpenMP][NFC] Outline common functionality (skipUntilPragmaOpenMPEnd) The same code was repeated multiple times, we put it in a function now.
2020-02-22 03:48:56 +08:00
skipUntilPragmaOpenMPEnd(OMPD_declare_reduction);
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
ConsumeAnyToken();
Directive = Actions.ActOnDeclStmt(Res, Loc, Tok.getLocation());
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-24 03:53:05 +08:00
} else {
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
SkipUntil(tok::annot_pragma_openmp_end);
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-24 03:53:05 +08:00
}
[OPENMP 4.0] Initial support for 'omp declare reduction' construct. Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct. User-defined reductions are defined as #pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )] These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting combined value after executing the combiner. As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced. Differential Revision: http://reviews.llvm.org/D11182 llvm-svn: 262582
2016-03-03 13:21:39 +08:00
break;
[OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive. This patch implements parsing and sema for "omp declare mapper" directive. User defined mapper, i.e., declare mapper directive, is a new feature in OpenMP 5.0. It is introduced to extend existing map clauses for the purpose of simplifying the copy of complex data structures between host and device (i.e., deep copy). An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(struct S s) map(s, s.d[0:s.len]) // Memory region that d points to is also mapped using this mapper. Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D56326 llvm-svn: 352906
2019-02-02 04:25:04 +08:00
case OMPD_declare_mapper: {
ConsumeToken();
if (DeclGroupPtrTy Res =
ParseOpenMPDeclareMapperDirective(/*AS=*/AS_none)) {
// Skip the last annot_pragma_openmp_end.
ConsumeAnnotationToken();
Directive = Actions.ActOnDeclStmt(Res, Loc, Tok.getLocation());
} else {
SkipUntil(tok::annot_pragma_openmp_end);
}
break;
}
[OPENMP] Initial parsing and sema analysis for 'flush' directive. llvm-svn: 213512
2014-07-21 19:26:11 +08:00
case OMPD_flush:
[OPENMP50]Add basic support for depobj construct. Added basic parsing/sema/serialization support for depobj directive.
2020-02-28 22:52:15 +08:00
case OMPD_depobj:
[OPENMP50]Initial support for scan directive. Addedi basic parsing/sema/serialization support for scan directive.
2020-03-20 19:03:01 +08:00
case OMPD_scan:
[OPENMP] Initial parsing and sema analysis of 'taskyield' directive. llvm-svn: 213355
2014-07-18 15:47:19 +08:00
case OMPD_taskyield:
[OPENMP] Initial parsing and sema analysis for 'barrier' directive. llvm-svn: 213360
2014-07-18 17:11:51 +08:00
case OMPD_barrier:
[OPENMP] Initial parsing and sema analysis for 'taskwait' directive. llvm-svn: 213363
2014-07-18 18:17:07 +08:00
case OMPD_taskwait:
[OPENMP 4.0] Initial support for 'omp cancellation point' construct. Add parsing and sema analysis for 'omp cancellation point' directive. llvm-svn: 241145
2015-07-01 14:57:41 +08:00
case OMPD_cancellation_point:
[OPENMP 4.0] Initial support for 'omp cancel' construct. Implemented parsing/sema analysis + (de)serialization. llvm-svn: 241253
2015-07-02 19:25:17 +08:00
case OMPD_cancel:
[OpenMP] Parsing + sema for "target enter data" directive. Patch by Arpith Jacob. Thanks! llvm-svn: 258165
2016-01-20 03:15:56 +08:00
case OMPD_target_enter_data:
[OpenMP] Parsing + sema for "target exit data" directive. Patch by Arpith Jacob. Thanks! llvm-svn: 258177
2016-01-20 04:04:50 +08:00
case OMPD_target_exit_data:
[OpenMP] Parsing and sema support for target update directive Summary: This patch is to add parsing and sema support for `target update` directive. Support for the `to` and `from` clauses will be added by a different patch. This patch also adds support for other clauses that are already implemented upstream and apply to `target update`, e.g. `device` and `if`. This patch is based on the original post by Kelvin Li. Reviewers: hfinkel, carlo.bertolli, kkwli0, arpith-jacob, ABataev Subscribers: caomhin, cfe-commits Differential Revision: http://reviews.llvm.org/D15944 llvm-svn: 270878
2016-05-27 01:30:50 +08:00
case OMPD_target_update:
[OPENMP51]Initial support for the interop directive. Added basic parsing/sema/serialization support for interop directive. Support for the 'init' clause. Differential Revision: https://reviews.llvm.org/D98558
2021-03-16 04:09:46 +08:00
case OMPD_interop:
PR40642: Fix determination of whether the final statement of a statement expression is a discarded-value expression. Summary: We used to get this wrong in three ways: 1) During parsing, an expression-statement followed by the }) ending a statement expression was always treated as producing the value of the statement expression. That's wrong for ({ if (1) expr; }) 2) During template instantiation, various kinds of statement (most statements not appearing directly in a compound-statement) were not treated as discarded-value expressions, resulting in missing volatile loads (etc). 3) In all contexts, an expression-statement with attributes was not treated as producing the value of the statement expression, eg ({ [[attr]] expr; }). Also fix incorrect enforcement of OpenMP rule that directives can "only be placed in the program at a position where ignoring or deleting the directive would result in a program with correct syntax". In particular, a label (be it goto, case, or default) should not affect whether directives are permitted. Reviewers: aaron.ballman, rjmccall Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57984 llvm-svn: 354090
2019-02-15 08:27:53 +08:00
if ((StmtCtx & ParsedStmtContext::AllowStandaloneOpenMPDirectives) ==
ParsedStmtContext()) {
[OPENMP] Initial parsing and sema analysis of 'taskyield' directive. llvm-svn: 213355
2014-07-18 15:47:19 +08:00
Diag(Tok, diag::err_omp_immediate_directive)
[OPENMP 4.5] Parsing/sema analysis for 'depend(source)' clause in 'ordered' directive. OpenMP 4.5 adds 'depend(source)' clause for 'ordered' directive to support cross-iteration dependence. Patch adds parsing and semantic analysis for this construct. llvm-svn: 255986
2015-12-18 13:05:56 +08:00
<< getOpenMPDirectiveName(DKind) << 0;
[OPENMP] Initial parsing and sema analysis of 'taskyield' directive. llvm-svn: 213355
2014-07-18 15:47:19 +08:00
}
HasAssociatedStatement = false;
[OPENMP] Initial parsing and sema analysis for 'flush' directive. llvm-svn: 213512
2014-07-21 19:26:11 +08:00
// Fall through for further analysis.
Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC. llvm-svn: 304478
2017-06-02 05:26:38 +08:00
LLVM_FALLTHROUGH;
[OPENMP] First changes for Parsing and Sema for 'omp simd' directive support llvm-svn: 202360
2014-02-27 16:29:12 +08:00
case OMPD_parallel:
[OPENMP] Initial support for '#pragma omp for' (fixed incompatibility with MSVC). llvm-svn: 211140
2014-06-18 12:14:57 +08:00
case OMPD_simd:
[OpenMP] Implement '#pragma omp tile', by Michael Kruse (@Meinersbur). The tile directive is in OpenMP's Technical Report 8 and foreseeably will be part of the upcoming OpenMP 5.1 standard. This implementation is based on an AST transformation providing a de-sugared loop nest. This makes it simple to forward the de-sugared transformation to loop associated directives taking the tiled loops. In contrast to other loop associated directives, the OMPTileDirective does not use CapturedStmts. Letting loop associated directives consume loops from different capture context would be difficult. A significant amount of code generation logic is taking place in the Sema class. Eventually, I would prefer if these would move into the CodeGen component such that we could make use of the OpenMPIRBuilder, together with flang. Only expressions converting between the language's iteration variable and the logical iteration space need to take place in the semantic analyzer: Getting the of iterations (e.g. the overload resolution of `std::distance`) and converting the logical iteration number to the iteration variable (e.g. overload resolution of `iteration + .omp.iv`). In clang, only CXXForRangeStmt is also represented by its de-sugared components. However, OpenMP loop are not defined as syntatic sugar. Starting with an AST-based approach allows us to gradually move generated AST statements into CodeGen, instead all at once. I would also like to refactor `checkOpenMPLoop` into its functionalities in a follow-up. In this patch it is used twice. Once for checking proper nesting and emitting diagnostics, and additionally for deriving the logical iteration space per-loop (instead of for the loop nest). Differential Revision: https://reviews.llvm.org/D76342
2021-02-13 03:26:59 +08:00
case OMPD_tile:
[OpenMP] Implement '#pragma omp unroll'. Implementation of the unroll directive introduced in OpenMP 5.1. Follows the approach from D76342 for the tile directive (i.e. AST-based, not using the OpenMPIRBuilder). Tries to use `llvm.loop.unroll.*` metadata where possible, but has to fall back to an AST representation of the outer loop if the partially unrolled generated loop is associated with another directive (because it needs to compute the number of iterations). Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D99459
2021-06-11 03:24:17 +08:00
case OMPD_unroll:
[OPENMP] Initial support for 'sections' directive. llvm-svn: 211685
2014-06-25 19:44:49 +08:00
case OMPD_for:
Parsing/Sema of directive omp for simd llvm-svn: 218029
2014-09-18 13:12:34 +08:00
case OMPD_for_simd:
[OPENMP] Initial parsing and sema analysis for 'section' directive. llvm-svn: 211767
2014-06-26 16:21:58 +08:00
case OMPD_sections:
[OPENMP] Initial parsing and sema analysis for 'single' directive. llvm-svn: 211774
2014-06-26 20:05:45 +08:00
case OMPD_single:
[OPENMP] Added initial support for 'omp parallel for'. llvm-svn: 212453
2014-07-07 21:01:15 +08:00
case OMPD_section:
[OPENMP] Parsing/Sema analysis of directive 'master' llvm-svn: 213237
2014-07-17 16:54:58 +08:00
case OMPD_master:
[OPENMP] Parsing/Sema of the OpenMP directive 'critical'. llvm-svn: 213510
2014-07-21 17:42:05 +08:00
case OMPD_critical:
[OPENMP] Parsing and sema analysis for 'omp parallel sections' directive. llvm-svn: 212516
2014-07-08 16:12:03 +08:00
case OMPD_parallel_for:
[OPENMP] Parsing/Sema of directive omp parallel for simd llvm-svn: 218299
2014-09-23 17:33:00 +08:00
case OMPD_parallel_for_simd:
[OPENMP] Parsing and sema analysis for 'omp task' directive. llvm-svn: 212804
2014-07-11 19:25:16 +08:00
case OMPD_parallel_sections:
[OpenMP50] Add parallel master construct Reviewers: ABataev, jdoerfert Reviewed By: ABataev Subscribers: rnk, jholewinski, guansong, arphaman, jfb, cfe-commits, sandoval, dreachem Tags: #clang Differential Revision: https://reviews.llvm.org/D70726
2019-12-06 02:43:48 +08:00
case OMPD_parallel_master:
[OPENMP] Initial parsing and sema analysis for 'ordered' directive. llvm-svn: 213616
2014-07-22 14:45:04 +08:00
case OMPD_task:
[OPENMP] Initial parsing and sema analysis for 'atomic' directive. llvm-svn: 213639
2014-07-22 18:10:35 +08:00
case OMPD_ordered:
[OPENMP] Initial parsing/sema analysis of 'target' directive. llvm-svn: 218110
2014-09-19 16:19:49 +08:00
case OMPD_atomic:
[OPENMP] 'omp teams' directive basic support. Includes parsing and semantic analysis for 'omp teams' directive support from OpenMP 4.0. Adds additional analysis to 'omp target' directive with 'omp teams' directive. llvm-svn: 219385
2014-10-09 12:18:56 +08:00
case OMPD_target:
[OPENMP] Support for '#pragma omp taskgroup' directive. Added parsing, sema analysis and codegen for '#pragma omp taskgroup' directive (OpenMP 4.0). The code for directive is generated the following way: #pragma omp taskgroup <body> void __kmpc_taskgroup(<loc>, thread_id); <body> void __kmpc_end_taskgroup(<loc>, thread_id); llvm-svn: 240011
2015-06-18 20:14:09 +08:00
case OMPD_teams:
Commit for http://reviews.llvm.org/D10765 for OpenMP 4 target data directive parsing and sema. This commit is on behalf of Kelvin Li. llvm-svn: 242785
2015-07-21 21:44:28 +08:00
case OMPD_taskgroup:
[OPENMP 4.5] Parsing/sema analysis for 'taskloop' directive. Adds initial parsing and semantic analysis for 'taskloop' directive. llvm-svn: 254367
2015-12-01 12:18:41 +08:00
case OMPD_target_data:
[OpenMP] Parsing + sema for target parallel directive. Summary: This patch adds parsing + sema for the target parallel directive and its clauses along with testcases. Reviewers: ABataev Differential Revision: http://reviews.llvm.org/D16553 Rebased to current trunk and updated test cases. llvm-svn: 258832
2016-01-27 02:48:41 +08:00
case OMPD_target_parallel:
[OpenMP] Parsing + sema for target parallel for directive. Summary: This patch adds parsing + sema for the target parallel for directive along with testcases. Reviewers: ABataev Differential Revision: http://reviews.llvm.org/D16759 llvm-svn: 259654
2016-02-03 23:46:42 +08:00
case OMPD_target_parallel_for:
[OPENMP 4.5] Parsing/sema support for 'omp taskloop simd' directive. OpenMP 4.5 adds directive 'taskloop simd'. Patch adds parsing/sema analysis for 'taskloop simd' directive and its clauses. llvm-svn: 254597
2015-12-03 17:40:15 +08:00
case OMPD_taskloop:
Add parse and sema of OpenMP distribute directive with all clauses except dist_schedule llvm-svn: 255498
2015-12-14 22:51:25 +08:00
case OMPD_taskloop_simd:
[OPENMP50]Support for 'master taskloop' directive. Added full support for master taskloop directive. llvm-svn: 374437
2019-10-11 04:13:02 +08:00
case OMPD_master_taskloop:
[OPENMP50]Add support for master taskloop simd. Added trsing/semantics/codegen for combined construct master taskloop simd. llvm-svn: 375255
2019-10-19 00:47:35 +08:00
case OMPD_master_taskloop_simd:
[OPENMP50]Add support for 'parallel master taskloop' construct. Added parsing/sema/codegen support for 'parallel master taskloop' constructs. Some of the clauses, like 'grainsize', 'num_tasks', 'final' and 'priority' are not supported in full, only constant expressions can be used currently in these clauses. llvm-svn: 374791
2019-10-15 01:17:41 +08:00
case OMPD_parallel_master_taskloop:
[OPENMP50]Add support for parallel master taskloop simd directive. Added full support for parallel master taskloop simd directive.
2019-10-25 22:27:13 +08:00
case OMPD_parallel_master_taskloop_simd:
Resubmission of http://reviews.llvm.org/D21564 after fixes. [OpenMP] Initial implementation of parse and sema for composite pragma 'distribute parallel for' This patch is an initial implementation for #distribute parallel for. The main differences that affect other pragmas are: The implementation of 'distribute parallel for' requires blocking of the associated loop, where blocks are "distributed" to different teams and iterations within each block are scheduled to parallel threads within each team. To implement blocking, sema creates two additional worksharing directive fields that are used to pass the team assigned block lower and upper bounds through the outlined function resulting from 'parallel'. In this way, scheduling for 'for' to threads can use those bounds. As a consequence of blocking, the stride of 'distribute' is not 1 but it is equal to the blocking size. This is returned by the runtime and sema prepares a DistIncrExpr variable to hold that value. As a consequence of blocking, the global upper bound (EnsureUpperBound) expression of the 'for' is not the original loop upper bound (e.g. in for(i = 0 ; i < N; i++) this is 'N') but it is the team-assigned block upper bound. Sema creates a new expression holding the calculation of the actual upper bound for 'for' as UB = min(UB, PrevUB), where UB is the loop upper bound, and PrevUB is the team-assigned block upper bound. llvm-svn: 273884
2016-06-27 22:55:37 +08:00
case OMPD_distribute:
[OpenMP] Sema and parse for 'distribute parallel for simd' Summary: This patch is an implementation of sema and parsing for the OpenMP composite pragma 'distribute parallel for simd'. Differential Revision: http://reviews.llvm.org/D21977 llvm-svn: 274530
2016-07-05 13:00:15 +08:00
case OMPD_distribute_parallel_for:
[OpenMP] Sema and parsing for 'distribute simd' pragma Summary: This patch is an implementation of sema and parsing for the OpenMP composite pragma 'distribute simd'. Differential Revision: http://reviews.llvm.org/D22007 llvm-svn: 274604
2016-07-06 12:45:38 +08:00
case OMPD_distribute_parallel_for_simd:
[OpenMP] Sema and parsing for 'target parallel for simd' pragma This patch is to implement sema and parsing for 'target parallel for simd' pragma. Differential Revision: http://reviews.llvm.org/D22096 llvm-svn: 275365
2016-07-14 10:54:56 +08:00
case OMPD_distribute_simd:
[OpenMP] Sema and parsing for 'target simd' pragma This patch is to implement sema and parsing for 'target simd' pragma. Differential Revision: https://reviews.llvm.org/D22479 llvm-svn: 276203
2016-07-21 06:57:10 +08:00
case OMPD_target_parallel_for_simd:
[OpenMP] Sema and parsing for 'teams distribute' pragma This patch is to implement sema and parsing for 'teams distribute' pragma. Differential Revision: https://reviews.llvm.org/D23189 llvm-svn: 277818
2016-08-05 22:37:37 +08:00
case OMPD_target_simd:
Re-apply patch r279045. llvm-svn: 285066
2016-10-25 20:50:55 +08:00
case OMPD_teams_distribute:
[OpenMP] Sema and parsing for 'teams distribute parallel for simd' pragma This patch is to implement sema and parsing for 'teams distribute parallel for simd' pragma. Differential Revision: https://reviews.llvm.org/D27084 llvm-svn: 288294
2016-12-01 07:51:03 +08:00
case OMPD_teams_distribute_simd:
[OpenMP] Sema and parsing for 'teams distribute parallel for' pragma This patch is to implement sema and parsing for 'teams distribute parallel for' pragma. Differential Revision: https://reviews.llvm.org/D27345 llvm-svn: 289179
2016-12-09 11:24:30 +08:00
case OMPD_teams_distribute_parallel_for_simd:
[OpenMP] Sema and parsing for 'target teams' pragma This patch is to implement sema and parsing for 'target teams' pragma. Differential Revision: https://reviews.llvm.org/D27818 llvm-svn: 290038
2016-12-17 13:48:59 +08:00
case OMPD_teams_distribute_parallel_for:
[OpenMP] Sema and parsing for 'target teams distribute' pragma This patch is to implement sema and parsing for 'target teams distribute' pragma. Differential Revision: https://reviews.llvm.org/D28015 llvm-svn: 290508
2016-12-25 12:52:54 +08:00
case OMPD_target_teams:
[OpenMP] Sema and parsing for 'target teams distribute parallel for’ pragma This patch is to implement sema and parsing for 'target teams distribute parallel for’ pragma. Differential Revision: https://reviews.llvm.org/D28160 llvm-svn: 290725
2016-12-30 06:16:30 +08:00
case OMPD_target_teams_distribute:
[OpenMP] Sema and parsing for 'target teams distribute parallel for simd’ pragma This patch is to implement sema and parsing for 'target teams distribute parallel for simd’ pragma. Differential Revision: https://reviews.llvm.org/D28202 llvm-svn: 290862
2017-01-03 13:23:48 +08:00
case OMPD_target_teams_distribute_parallel_for:
[OpenMP] Sema and parsing for 'target teams distribute simd’ pragma This patch is to implement sema and parsing for 'target teams distribute simd’ pragma. Differential Revision: https://reviews.llvm.org/D28252 llvm-svn: 291579
2017-01-11 02:08:18 +08:00
case OMPD_target_teams_distribute_parallel_for_simd:
[OPENMP51]Initial support for the dispatch directive. Added basic parsing/sema/serialization support for dispatch directive. Differential Revision: https://reviews.llvm.org/D99537
2021-03-23 09:13:29 +08:00
case OMPD_target_teams_distribute_simd:
[OpenMP51] Initial support for masked directive and filter clause Adds basic parsing/sema/serialization support for the #pragma omp masked directive. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D99995
2021-04-10 03:00:36 +08:00
case OMPD_dispatch:
case OMPD_masked: {
[OPENMP50]Add basic support for depobj construct. Added basic parsing/sema/serialization support for depobj directive.
2020-02-28 22:52:15 +08:00
// Special processing for flush and depobj clauses.
Token ImplicitTok;
bool ImplicitClauseAllowed = false;
if (DKind == OMPD_flush || DKind == OMPD_depobj) {
ImplicitTok = Tok;
ImplicitClauseAllowed = true;
}
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
ConsumeToken();
[OPENMP] Parsing/Sema of the OpenMP directive 'critical'. llvm-svn: 213510
2014-07-21 17:42:05 +08:00
// Parse directive name of the 'critical' directive if any.
if (DKind == OMPD_critical) {
BalancedDelimiterTracker T(*this, tok::l_paren,
tok::annot_pragma_openmp_end);
if (!T.consumeOpen()) {
if (Tok.isAnyIdentifier()) {
DirName =
DeclarationNameInfo(Tok.getIdentifierInfo(), Tok.getLocation());
ConsumeAnyToken();
} else {
Diag(Tok, diag::err_omp_expected_identifier_for_critical);
}
T.consumeClose();
}
[OPENMP 4.0] Initial support for 'omp cancel' construct. Implemented parsing/sema analysis + (de)serialization. llvm-svn: 241253
2015-07-02 19:25:17 +08:00
} else if (DKind == OMPD_cancellation_point || DKind == OMPD_cancel) {
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-24 03:53:05 +08:00
CancelRegion = parseOpenMPDirectiveKind(*this);
[OPENMP 4.0] Initial support for 'omp cancellation point' construct. Add parsing and sema analysis for 'omp cancellation point' directive. llvm-svn: 241145
2015-07-01 14:57:41 +08:00
if (Tok.isNot(tok::annot_pragma_openmp_end))
ConsumeToken();
[OPENMP] Parsing/Sema of the OpenMP directive 'critical'. llvm-svn: 213510
2014-07-21 17:42:05 +08:00
}
OpenMP: Data-sharing attributes analysis and clause 'shared' (fixed test threadprivate_messages.cpp) llvm-svn: 190183
2013-09-07 02:03:48 +08:00
[OPENMP] Initial support for '#pragma omp for' (fixed incompatibility with MSVC). llvm-svn: 211140
2014-06-18 12:14:57 +08:00
if (isOpenMPLoopDirective(DKind))
ScopeFlags |= Scope::OpenMPLoopDirectiveScope;
if (isOpenMPSimdDirective(DKind))
ScopeFlags |= Scope::OpenMPSimdDirectiveScope;
ParseScope OMPDirectiveScope(this, ScopeFlags);
[OPENMP] Parsing and sema analysis for 'copyprivate' clause. llvm-svn: 211886
2014-06-27 18:37:06 +08:00
Actions.StartOpenMPDSABlock(DKind, DirName, Actions.getCurScope(), Loc);
OpenMP: Data-sharing attributes analysis and clause 'shared' (fixed test threadprivate_messages.cpp) llvm-svn: 190183
2013-09-07 02:03:48 +08:00
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
while (Tok.isNot(tok::annot_pragma_openmp_end)) {
OpenMP 5.0 metadirective This patch supports OpenMP 5.0 metadirective features. It is implemented keeping the OpenMP 5.1 features like dynamic user condition in mind. A new function, getBestWhenMatchForContext, is defined in llvm/Frontend/OpenMP/OMPContext.h Currently this function return the index of the when clause with the highest score from the ones applicable in the Context. But this function is declared with an array which can be used in OpenMP 5.1 implementation to select all the valid when clauses which can be resolved in runtime. Currently this array is set to null by default and its implementation is left for future. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D91944
2021-09-18 05:03:01 +08:00
// If we are parsing for a directive within a metadirective, the directive
// ends with a ')'.
if (ReadDirectiveWithinMetadirective && Tok.is(tok::r_paren)) {
while (Tok.isNot(tok::annot_pragma_openmp_end))
ConsumeAnyToken();
break;
}
[OPENMP50]Add basic support for depobj construct. Added basic parsing/sema/serialization support for depobj directive.
2020-02-28 22:52:15 +08:00
bool HasImplicitClause = false;
if (ImplicitClauseAllowed && Tok.is(tok::l_paren)) {
HasImplicitClause = true;
[OPENMP50]Add parsing/sema for acq_rel clause. Added basic support (representation + parsing/sema/(de)serialization) for acq_rel clause in flush/atomic directives.
2020-02-07 05:30:23 +08:00
// Push copy of the current token back to stream to properly parse
[OPENMP50]Add basic support for depobj construct. Added basic parsing/sema/serialization support for depobj directive.
2020-02-28 22:52:15 +08:00
// pseudo-clause OMPFlushClause or OMPDepobjClause.
[OPENMP50]Add parsing/sema for acq_rel clause. Added basic support (representation + parsing/sema/(de)serialization) for acq_rel clause in flush/atomic directives.
2020-02-07 05:30:23 +08:00
PP.EnterToken(Tok, /*IsReinject*/ true);
[OPENMP50]Add basic support for depobj construct. Added basic parsing/sema/serialization support for depobj directive.
2020-02-28 22:52:15 +08:00
PP.EnterToken(ImplicitTok, /*IsReinject*/ true);
[OPENMP50]Add parsing/sema for acq_rel clause. Added basic support (representation + parsing/sema/(de)serialization) for acq_rel clause in flush/atomic directives.
2020-02-07 05:30:23 +08:00
ConsumeAnyToken();
}
[OPENMP50]Add basic support for depobj construct. Added basic parsing/sema/serialization support for depobj directive.
2020-02-28 22:52:15 +08:00
OpenMPClauseKind CKind = Tok.isAnnotation()
? OMPC_unknown
: getOpenMPClauseKind(PP.getSpelling(Tok));
if (HasImplicitClause) {
assert(CKind == OMPC_unknown && "Must be unknown implicit clause.");
if (DKind == OMPD_flush) {
CKind = OMPC_flush;
} else {
assert(DKind == OMPD_depobj &&
"Expected flush or depobj directives.");
CKind = OMPC_depobj;
}
}
// No more implicit clauses allowed.
ImplicitClauseAllowed = false;
[OPENMP] Do not emit references to original variables in 'private' clause. Currently if the variable is captured in captured region, capture record for this region stores reference to this variable for future use. But we don't need to provide the reference to the original variable if it was explicitly marked as private in the 'private' clause of the OpenMP construct, this variable is replaced by private copy. Differential Revision: http://reviews.llvm.org/D9550 llvm-svn: 240377
2015-06-23 12:51:00 +08:00
Actions.StartOpenMPClause(CKind);
[OPENMP50]Add basic support for depobj construct. Added basic parsing/sema/serialization support for depobj directive.
2020-02-28 22:52:15 +08:00
HasImplicitClause = false;
[OpenMP][NFCI] Move OpenMP clause information to `lib/Frontend/OpenMP` This is a cleanup and normalization patch that also enables reuse with Flang later on. A follow up will clean up and move the directive -> clauses mapping. Reviewed By: fghanim Differential Revision: https://reviews.llvm.org/D77112
2020-03-31 08:58:40 +08:00
OMPClause *Clause = ParseOpenMPClause(
DKind, CKind, !FirstClauses[unsigned(CKind)].getInt());
FirstClauses[unsigned(CKind)].setInt(true);
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
if (Clause) {
[OpenMP][NFCI] Move OpenMP clause information to `lib/Frontend/OpenMP` This is a cleanup and normalization patch that also enables reuse with Flang later on. A follow up will clean up and move the directive -> clauses mapping. Reviewed By: fghanim Differential Revision: https://reviews.llvm.org/D77112
2020-03-31 08:58:40 +08:00
FirstClauses[unsigned(CKind)].setPointer(Clause);
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
Clauses.push_back(Clause);
}
// Skip ',' if any.
if (Tok.is(tok::comma))
ConsumeToken();
[OPENMP] Do not emit references to original variables in 'private' clause. Currently if the variable is captured in captured region, capture record for this region stores reference to this variable for future use. But we don't need to provide the reference to the original variable if it was explicitly marked as private in the 'private' clause of the OpenMP construct, this variable is replaced by private copy. Differential Revision: http://reviews.llvm.org/D9550 llvm-svn: 240377
2015-06-23 12:51:00 +08:00
Actions.EndOpenMPClause();
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
}
// End location of the directive.
EndLoc = Tok.getLocation();
// Consume final annot_pragma_openmp_end.
Fix the location of "missing ';'" suggestions after annotation tokens. We were incorrectly setting PrevTokLocation to the first token in the annotation token instead of the last when consuming it. To fix this without adding a complex switch to the hot path through ConsumeToken, we now have a ConsumeAnnotationToken function for consuming annotation tokens in addition to the other Consume*Token special case functions. llvm-svn: 303372
2017-05-19 03:21:48 +08:00
ConsumeAnnotationToken();
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
[OPENMP 4.5] Parsing/sema analysis for 'depend(source)' clause in 'ordered' directive. OpenMP 4.5 adds 'depend(source)' clause for 'ordered' directive to support cross-iteration dependence. Patch adds parsing and semantic analysis for this construct. llvm-svn: 255986
2015-12-18 13:05:56 +08:00
// OpenMP [2.13.8, ordered Construct, Syntax]
// If the depend clause is specified, the ordered construct is a stand-alone
// directive.
[OpenMP][NFCI] Move OpenMP clause information to `lib/Frontend/OpenMP` This is a cleanup and normalization patch that also enables reuse with Flang later on. A follow up will clean up and move the directive -> clauses mapping. Reviewed By: fghanim Differential Revision: https://reviews.llvm.org/D77112
2020-03-31 08:58:40 +08:00
if (DKind == OMPD_ordered && FirstClauses[unsigned(OMPC_depend)].getInt()) {
PR40642: Fix determination of whether the final statement of a statement expression is a discarded-value expression. Summary: We used to get this wrong in three ways: 1) During parsing, an expression-statement followed by the }) ending a statement expression was always treated as producing the value of the statement expression. That's wrong for ({ if (1) expr; }) 2) During template instantiation, various kinds of statement (most statements not appearing directly in a compound-statement) were not treated as discarded-value expressions, resulting in missing volatile loads (etc). 3) In all contexts, an expression-statement with attributes was not treated as producing the value of the statement expression, eg ({ [[attr]] expr; }). Also fix incorrect enforcement of OpenMP rule that directives can "only be placed in the program at a position where ignoring or deleting the directive would result in a program with correct syntax". In particular, a label (be it goto, case, or default) should not affect whether directives are permitted. Reviewers: aaron.ballman, rjmccall Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57984 llvm-svn: 354090
2019-02-15 08:27:53 +08:00
if ((StmtCtx & ParsedStmtContext::AllowStandaloneOpenMPDirectives) ==
ParsedStmtContext()) {
[OPENMP 4.5] Parsing/sema analysis for 'depend(source)' clause in 'ordered' directive. OpenMP 4.5 adds 'depend(source)' clause for 'ordered' directive to support cross-iteration dependence. Patch adds parsing and semantic analysis for this construct. llvm-svn: 255986
2015-12-18 13:05:56 +08:00
Diag(Loc, diag::err_omp_immediate_directive)
<< getOpenMPDirectiveName(DKind) << 1
<< getOpenMPClauseName(OMPC_depend);
}
HasAssociatedStatement = false;
}
[OpenMP] Implement '#pragma omp tile', by Michael Kruse (@Meinersbur). The tile directive is in OpenMP's Technical Report 8 and foreseeably will be part of the upcoming OpenMP 5.1 standard. This implementation is based on an AST transformation providing a de-sugared loop nest. This makes it simple to forward the de-sugared transformation to loop associated directives taking the tiled loops. In contrast to other loop associated directives, the OMPTileDirective does not use CapturedStmts. Letting loop associated directives consume loops from different capture context would be difficult. A significant amount of code generation logic is taking place in the Sema class. Eventually, I would prefer if these would move into the CodeGen component such that we could make use of the OpenMPIRBuilder, together with flang. Only expressions converting between the language's iteration variable and the logical iteration space need to take place in the semantic analyzer: Getting the of iterations (e.g. the overload resolution of `std::distance`) and converting the logical iteration number to the iteration variable (e.g. overload resolution of `iteration + .omp.iv`). In clang, only CXXForRangeStmt is also represented by its de-sugared components. However, OpenMP loop are not defined as syntatic sugar. Starting with an AST-based approach allows us to gradually move generated AST statements into CodeGen, instead all at once. I would also like to refactor `checkOpenMPLoop` into its functionalities in a follow-up. In this patch it is used twice. Once for checking proper nesting and emitting diagnostics, and additionally for deriving the logical iteration space per-loop (instead of for the loop nest). Differential Revision: https://reviews.llvm.org/D76342
2021-02-13 03:26:59 +08:00
if (DKind == OMPD_tile && !FirstClauses[unsigned(OMPC_sizes)].getInt()) {
Diag(Loc, diag::err_omp_required_clause)
<< getOpenMPDirectiveName(OMPD_tile) << "sizes";
}
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
StmtResult AssociatedStmt;
[OPENMP] Initial parsing and sema analysis of 'taskyield' directive. llvm-svn: 213355
2014-07-18 15:47:19 +08:00
if (HasAssociatedStatement) {
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
// The body is a block scope like in Lambdas and Blocks.
[OPENMP] Parsing and sema analysis for 'copyprivate' clause. llvm-svn: 211886
2014-06-27 18:37:06 +08:00
Actions.ActOnOpenMPRegionStart(DKind, getCurScope());
Fix crash when trying to pack-expand a GNU statement expression. We could in principle support such pack expansion, using techniques similar to what we do for pack expansion of lambdas, but it's not clear it's worthwhile. For now at least, cleanly reject these cases rather than crashing. llvm-svn: 324160
2018-02-03 08:44:57 +08:00
// FIXME: We create a bogus CompoundStmt scope to hold the contents of
// the captured region. Code elsewhere assumes that any FunctionScopeInfo
// should have at least one compound statement scope within it.
[OPENMP]Fix PR46357: Do not allow types declarations in pragmas. Summary: Compiler may erroneously treat current context in OpenMP pragmas as the context where new type declaration/definition is allowed. But the declartation/definition of the new types in OpenMP pragmas should not be allowed. Reviewers: jdoerfert Subscribers: yaxunl, guansong, sstefan1, cfe-commits, caomhin Tags: #clang Differential Revision: https://reviews.llvm.org/D82019
2020-06-17 23:02:49 +08:00
ParsingOpenMPDirectiveRAII NormalScope(*this, /*Value=*/false);
[clang][OpenMP] Use OpenMPIRBuilder for workshare loops. Initial support for using the OpenMPIRBuilder by clang to generate loops using the OpenMPIRBuilder. This initial support is intentionally limited to: * Only the worksharing-loop directive. * Recognizes only the nowait clause. * No loop nests with more than one loop. * Untested with templates, exceptions. * Semantic checking left to the existing infrastructure. This patch introduces a new AST node, OMPCanonicalLoop, which becomes parent of any loop that has to adheres to the restrictions as specified by the OpenMP standard. These restrictions allow OMPCanonicalLoop to provide the following additional information that depends on base language semantics: * The distance function: How many loop iterations there will be before entering the loop nest. * The loop variable function: Conversion from a logical iteration number to the loop variable. These allow the OpenMPIRBuilder to act solely using logical iteration numbers without needing to be concerned with iterator semantics between calling the distance function and determining what the value of the loop variable ought to be. Any OpenMP logical should be done by the OpenMPIRBuilder such that it can be reused MLIR OpenMP dialect and thus by flang. The distance and loop variable function are implemented using lambdas (or more exactly: CapturedStmt because lambda implementation is more interviewed with the parser). It is up to the OpenMPIRBuilder how they are called which depends on what is done with the loop. By default, these are emitted as outlined functions but we might think about emitting them inline as the OpenMPRuntime does. For compatibility with the current OpenMP implementation, even though not necessary for the OpenMPIRBuilder, OMPCanonicalLoop can still be nested within OMPLoopDirectives' CapturedStmt. Although OMPCanonicalLoop's are not currently generated when the OpenMPIRBuilder is not enabled, these can just be skipped when not using the OpenMPIRBuilder in case we don't want to make the AST dependent on the EnableOMPBuilder setting. Loop nests with more than one loop require support by the OpenMPIRBuilder (D93268). A simple implementation of non-rectangular loop nests would add another lambda function that returns whether a loop iteration of the rectangular overapproximation is also within its non-rectangular subset. Reviewed By: jdenny Differential Revision: https://reviews.llvm.org/D94973
2021-03-04 07:15:32 +08:00
{
Sema::CompoundScopeRAII Scope(Actions);
AssociatedStmt = ParseStatement();
if (AssociatedStmt.isUsable() && isOpenMPLoopDirective(DKind) &&
getLangOpts().OpenMPIRBuilder)
[OpenMP][OpenMPIRBuilder] Implement loop unrolling. Recommit of 707ce34b06190e275572c3c46843036db1bab6d1. Don't introduce a dependency to the LLVMPasses component, instead register the required passes individually. Add methods for loop unrolling to the OpenMPIRBuilder class and use them in Clang if `-fopenmp-enable-irbuilder` is enabled. The unrolling methods are: * `unrollLoopFull` * `unrollLoopPartial` * `unrollLoopHeuristic` `unrollLoopPartial` and `unrollLoopHeuristic` can use compiler heuristics to automatically determine the unroll factor. If possible, that is if no CanonicalLoopInfo is required to pass to another method, metadata for LLVM's LoopUnrollPass is added. Otherwise the unroll factor is determined using the same heurstics as user by LoopUnrollPass. Not requiring a CanonicalLoopInfo, especially with `unrollLoopHeuristic` allows greater flexibility. With full unrolling and partial unrolling with known unroll factor, instead of duplicating instructions by the OpenMPIRBuilder, the full unroll is still delegated to the LoopUnrollPass. In case of partial unrolling the loop is first tiled using the existing `tileLoops` methods, then the inner loop fully unrolled using the same mechanism. Reviewed By: jdoerfert, kiranchandramohan Differential Revision: https://reviews.llvm.org/D107764
2021-09-05 07:50:49 +08:00
AssociatedStmt = Actions.ActOnOpenMPLoopnest(AssociatedStmt.get());
[clang][OpenMP] Use OpenMPIRBuilder for workshare loops. Initial support for using the OpenMPIRBuilder by clang to generate loops using the OpenMPIRBuilder. This initial support is intentionally limited to: * Only the worksharing-loop directive. * Recognizes only the nowait clause. * No loop nests with more than one loop. * Untested with templates, exceptions. * Semantic checking left to the existing infrastructure. This patch introduces a new AST node, OMPCanonicalLoop, which becomes parent of any loop that has to adheres to the restrictions as specified by the OpenMP standard. These restrictions allow OMPCanonicalLoop to provide the following additional information that depends on base language semantics: * The distance function: How many loop iterations there will be before entering the loop nest. * The loop variable function: Conversion from a logical iteration number to the loop variable. These allow the OpenMPIRBuilder to act solely using logical iteration numbers without needing to be concerned with iterator semantics between calling the distance function and determining what the value of the loop variable ought to be. Any OpenMP logical should be done by the OpenMPIRBuilder such that it can be reused MLIR OpenMP dialect and thus by flang. The distance and loop variable function are implemented using lambdas (or more exactly: CapturedStmt because lambda implementation is more interviewed with the parser). It is up to the OpenMPIRBuilder how they are called which depends on what is done with the loop. By default, these are emitted as outlined functions but we might think about emitting them inline as the OpenMPRuntime does. For compatibility with the current OpenMP implementation, even though not necessary for the OpenMPIRBuilder, OMPCanonicalLoop can still be nested within OMPLoopDirectives' CapturedStmt. Although OMPCanonicalLoop's are not currently generated when the OpenMPIRBuilder is not enabled, these can just be skipped when not using the OpenMPIRBuilder in case we don't want to make the AST dependent on the EnableOMPBuilder setting. Loop nests with more than one loop require support by the OpenMPIRBuilder (D93268). A simple implementation of non-rectangular loop nests would add another lambda function that returns whether a loop iteration of the rectangular overapproximation is also within its non-rectangular subset. Reviewed By: jdenny Differential Revision: https://reviews.llvm.org/D94973
2021-03-04 07:15:32 +08:00
}
[OPENMP] Fix crash on private variables not used in OpenMP region. llvm-svn: 233902
2015-04-02 15:48:16 +08:00
AssociatedStmt = Actions.ActOnOpenMPRegionEnd(AssociatedStmt, Clauses);
[OPENMP] Initial support for asynchronous data update, NFC. OpenMP 5.0 introduces asynchronous data update/dependecies clauses on target data directives. Patch adds initial support for outer task regions to use task-based codegen for future async target data directives. llvm-svn: 318781
2017-11-22 01:08:48 +08:00
} else if (DKind == OMPD_target_update || DKind == OMPD_target_enter_data ||
DKind == OMPD_target_exit_data) {
Actions.ActOnOpenMPRegionStart(DKind, getCurScope());
Fix crash when trying to pack-expand a GNU statement expression. We could in principle support such pack expansion, using techniques similar to what we do for pack expansion of lambdas, but it's not clear it's worthwhile. For now at least, cleanly reject these cases rather than crashing. llvm-svn: 324160
2018-02-03 08:44:57 +08:00
AssociatedStmt = (Sema::CompoundScopeRAII(Actions),
Actions.ActOnCompoundStmt(Loc, Loc, llvm::None,
/*isStmtExpr=*/false));
[OPENMP] Initial support for asynchronous data update, NFC. OpenMP 5.0 introduces asynchronous data update/dependecies clauses on target data directives. Patch adds initial support for outer task regions to use task-based codegen for future async target data directives. llvm-svn: 318781
2017-11-22 01:08:48 +08:00
AssociatedStmt = Actions.ActOnOpenMPRegionEnd(AssociatedStmt, Clauses);
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
}
[OPENMP 4.1] Parsing/sema analysis for extended format of 'if' clause. OpenMP 4.1 added special 'directive-name-modifier' to the 'if' clause. Format of 'if' clause is as follows: ``` if([ directive-name-modifier :] scalar-logical-expression) ``` The restriction rules are also changed. 1. If any 'if' clause on the directive includes a 'directive-name-modifier' then all 'if' clauses on the directive must include a 'directive-name-modifier'. 2. At most one 'if' clause without a 'directive-name-modifier' can appear on the directive. 3. At most one 'if' clause with some particular 'directive-name-modifier' can appear on the directive. 'directive-name-modifier' is important for combined directives and allows to separate conditions in 'if' clause for simple sub-directives in combined directive. This 'directive-name-modifier' identifies the sub-directive to which this 'if' clause must be applied. llvm-svn: 246747
2015-09-03 15:23:48 +08:00
Directive = Actions.ActOnOpenMPExecutableDirective(
DKind, DirName, CancelRegion, Clauses, AssociatedStmt.get(), Loc,
EndLoc);
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
// Exit scope.
OpenMP: Data-sharing attributes analysis and clause 'shared' (fixed test threadprivate_messages.cpp) llvm-svn: 190183
2013-09-07 02:03:48 +08:00
Actions.EndOpenMPDSABlock(Directive.get());
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
OMPDirectiveScope.Exit();
break;
[OPENMP] Reformatting of parsing code for OpenMP constructs. llvm-svn: 209714
2014-05-28 14:15:33 +08:00
}
[OPENMP 4.0] Initial support for '#pragma omp declare simd' directive. Initial parsing/sema/serialization/deserialization support for '#pragma omp declare simd' directive. The 'declare simd' construct can be applied to a function to enable the creation of one or more versions that can process multiple arguments using SIMD instructions from a single invocation from a SIMD loop. If the function has any declarations, then the declare simd construct for any declaration that has one must be equivalent to the one specified for the definition. Otherwise, the result is unspecified. This pragma can be applied many times to the same declaration. Internally this pragma is represented as an attribute. But we need special processing for this pragma because it must be used before function declaration, this directive is applied to. Differential Revision: http://reviews.llvm.org/D10599 llvm-svn: 264853
2016-03-30 18:43:55 +08:00
case OMPD_declare_simd:
[OPENMP] Parsing and Sema support for 'omp declare target' directive Add parsing, sema analysis for 'declare target' construct for OpenMP 4.0 (4.5 support will be added in separate patch). The declare target directive specifies that variables, functions (C, C++ and Fortran), and subroutines (Fortran) are mapped to a device. The declare target directive is a declarative directive. In Clang declare target is implemented as implicit attribute for the declaration. The syntax of the declare target directive is as follows: #pragma omp declare target declarations-definition-seq #pragma omp end declare target Based on patch from Michael Wong http://reviews.llvm.org/D15321 llvm-svn: 265530
2016-04-06 19:38:59 +08:00
case OMPD_declare_target:
[OpenMP] Overhaul `declare target` handling This patch fixes various issues with our prior `declare target` handling and extends it to support `omp begin declare target` as well. This started with PR49649 in mind, trying to provide a way for users to avoid the "ref" global use introduced for globals with internal linkage. From there it went down the rabbit hole, e.g., all variables, even `nohost` ones, were emitted into the device code so it was impossible to determine if "ref" was needed late in the game (based on the name only). To make it really useful, `begin declare target` was needed as it can carry the `device_type`. Not emitting variables eagerly had a ripple effect. Finally, the precedence of the (explicit) declare target list items needed to be taken into account, that meant we cannot just look for any declare target attribute to make a decision. This caused the handling of functions to require fixup as well. I tried to clean up things while I was at it, e.g., we should not "parse declarations and defintions" as part of OpenMP parsing, this will always break at some point. Instead, we keep track what region we are in and act on definitions and declarations instead, this is what we do for declare variant and other begin/end directives already. Highlights: - new diagnosis for restrictions specificed in the standard, - delayed emission of globals not mentioned in an explicit list of a declare target, - omission of `nohost` globals on the host and `host` globals on the device, - no explicit parsing of declarations in-between `omp [begin] declare variant` and the corresponding end anymore, regular parsing instead, - precedence for explicit mentions in `declare target` lists over implicit mentions in the declaration-definition-seq, and - `omp allocate` declarations will now replace an earlier emitted global, if necessary. --- Notes: The patch is larger than I hoped but it turns out that most changes do on their own lead to "inconsistent states", which seem less desirable overall. After working through this I feel the standard should remove the explicit declare target forms as the delayed emission is horrible. That said, while we delay things anyway, it seems to me we check too often for the current status even though that is often not sufficient to act upon. There seems to be a lot of duplication that can probably be trimmed down. Eagerly emitting some things seems pretty weak as an argument to keep so much logic around. --- Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D101030
2021-04-22 13:57:28 +08:00
case OMPD_begin_declare_target:
[OPENMP] Parsing and Sema support for 'omp declare target' directive Add parsing, sema analysis for 'declare target' construct for OpenMP 4.0 (4.5 support will be added in separate patch). The declare target directive specifies that variables, functions (C, C++ and Fortran), and subroutines (Fortran) are mapped to a device. The declare target directive is a declarative directive. In Clang declare target is implemented as implicit attribute for the declaration. The syntax of the declare target directive is as follows: #pragma omp declare target declarations-definition-seq #pragma omp end declare target Based on patch from Michael Wong http://reviews.llvm.org/D15321 llvm-svn: 265530
2016-04-06 19:38:59 +08:00
case OMPD_end_declare_target:
[OPENMP] Add support for OMP5 requires directive + unified_address clause Add support for OMP5.0 requires directive and unified_address clause. Patches to follow will include support for additional clauses. Differential Revision: https://reviews.llvm.org/D52359 llvm-svn: 343063
2018-09-26 12:28:39 +08:00
case OMPD_requires:
[OpenMP] `omp begin/end declare variant` - part 1, parsing This is the first part extracted from D71179 and cleaned up. This patch provides parsing support for `omp begin/end declare variant`, as defined in OpenMP technical report 8 (TR8) [0]. A major purpose of this patch is to provide proper math.h/cmath support for OpenMP target offloading. See PR42061, PR42798, PR42799. The current code was developed with this feature in mind, see [1]. [0] https://www.openmp.org/wp-content/uploads/openmp-TR8.pdf [1] https://reviews.llvm.org/D61399#change-496lQkg0mhRN Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D74941
2020-02-21 09:50:47 +08:00
case OMPD_begin_declare_variant:
case OMPD_end_declare_variant:
[OPENMP5.0]Add basic support for declare variant directive. Added basic support for declare variant directive and its match clause with user context selector. llvm-svn: 371892
2019-09-14 04:18:17 +08:00
case OMPD_declare_variant:
[OPENMP 4.0] Initial support for '#pragma omp declare simd' directive. Initial parsing/sema/serialization/deserialization support for '#pragma omp declare simd' directive. The 'declare simd' construct can be applied to a function to enable the creation of one or more versions that can process multiple arguments using SIMD instructions from a single invocation from a SIMD loop. If the function has any declarations, then the declare simd construct for any declaration that has one must be equivalent to the one specified for the definition. Otherwise, the result is unspecified. This pragma can be applied many times to the same declaration. Internally this pragma is represented as an attribute. But we need special processing for this pragma because it must be used before function declaration, this directive is applied to. Differential Revision: http://reviews.llvm.org/D10599 llvm-svn: 264853
2016-03-30 18:43:55 +08:00
Diag(Tok, diag::err_omp_unexpected_directive)
[OPENMP] Fix parsing of the directives with inner directives. The parsing may lead to compiler hanging because of the incorrect processing of inner OpenMP pragmas. llvm-svn: 325369
2018-02-17 02:36:44 +08:00
<< 1 << getOpenMPDirectiveName(DKind);
[OPENMP 4.0] Initial support for '#pragma omp declare simd' directive. Initial parsing/sema/serialization/deserialization support for '#pragma omp declare simd' directive. The 'declare simd' construct can be applied to a function to enable the creation of one or more versions that can process multiple arguments using SIMD instructions from a single invocation from a SIMD loop. If the function has any declarations, then the declare simd construct for any declaration that has one must be equivalent to the one specified for the definition. Otherwise, the result is unspecified. This pragma can be applied many times to the same declaration. Internally this pragma is represented as an attribute. But we need special processing for this pragma because it must be used before function declaration, this directive is applied to. Differential Revision: http://reviews.llvm.org/D10599 llvm-svn: 264853
2016-03-30 18:43:55 +08:00
SkipUntil(tok::annot_pragma_openmp_end);
break;
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
case OMPD_unknown:
[flang][openmp] Use common Directive and Clause enum from llvm/Frontend Summary: This patch is removing the custom enumeration for OpenMP Directives and Clauses and replace them with the newly tablegen generated one from llvm/Frontend. This is a first patch and some will follow to share the same infrastructure where possible. The next patch should use the clauses allowance defined in the tablegen file. Reviewers: jdoerfert, DavidTruby, sscalpone, kiranchandramohan, ichoyjx Reviewed By: DavidTruby, ichoyjx Subscribers: jholewinski, cfe-commits, dblaikie, MaskRay, ymandel, ichoyjx, mgorny, yaxunl, guansong, jfb, sstefan1, aaron.ballman, llvm-commits Tags: #llvm, #flang, #clang Differential Revision: https://reviews.llvm.org/D82906
2020-07-02 08:57:11 +08:00
default:
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
Diag(Tok, diag::err_omp_unknown_directive);
Revert "[OPENMP] Fix for parsing OpenMP directives with extra braces, brackets and parens" These parser changes were redundant. The same or better recovery can be achieved with a one-line fix to SkipUntil() due to land in the next commit. This reverts commit r197553. llvm-svn: 197597
2013-12-19 03:10:49 +08:00
SkipUntil(tok::annot_pragma_openmp_end);
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
break;
}
return Directive;
}
[OpenMP] Parse+Sema for '#pragma omp declare target' syntax version 4.5 Support OpenMP version 4.5 syntax for #pragma omp declare target. Syntax: #pragma omp declare target (extended-list) new-line or #pragma omp declare target clause[ [,] clause ... ] new-line Where clause is one of the following: to(extended-list) link(list) Differential Revision: http://reviews.llvm.org/D20011 llvm-svn: 268925
2016-05-09 22:59:13 +08:00
// Parses simple list:
// simple-variable-list:
// '(' id-expression {, id-expression} ')'
//
bool Parser::ParseOpenMPSimpleVarList(
OpenMPDirectiveKind Kind,
[OpenMP][NFC] Clang format ParseOpenMP ParseOpenMP.cpp was pretty much clang-formatted except a few minor locations. Let's make it a clang formatted file. Reviewed By: JonChesterfield Differential Revision: https://reviews.llvm.org/D90440
2020-10-30 07:44:28 +08:00
const llvm::function_ref<void(CXXScopeSpec &, DeclarationNameInfo)>
&Callback,
[OpenMP] Parse+Sema for '#pragma omp declare target' syntax version 4.5 Support OpenMP version 4.5 syntax for #pragma omp declare target. Syntax: #pragma omp declare target (extended-list) new-line or #pragma omp declare target clause[ [,] clause ... ] new-line Where clause is one of the following: to(extended-list) link(list) Differential Revision: http://reviews.llvm.org/D20011 llvm-svn: 268925
2016-05-09 22:59:13 +08:00
bool AllowScopeSpecifier) {
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 14:34:35 +08:00
// Parse '('.
Revert "[OPENMP] Fix for parsing OpenMP directives with extra braces, brackets and parens" These parser changes were redundant. The same or better recovery can be achieved with a one-line fix to SkipUntil() due to land in the next commit. This reverts commit r197553. llvm-svn: 197597
2013-12-19 03:10:49 +08:00
BalancedDelimiterTracker T(*this, tok::l_paren, tok::annot_pragma_openmp_end);
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
if (T.expectAndConsume(diag::err_expected_lparen_after,
[OpenMP][NFCI] Introduce llvm/IR/OpenMPConstants.h Summary: The new OpenMPConstants.h is a location for all OpenMP related constants (and helpers) to live. This patch moves the directives there (the enum OpenMPDirectiveKind) and rewires Clang to use the new location. Initially part of D69785. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: jholewinski, ppenzin, penzn, llvm-commits, cfe-commits, jfb, guansong, bollu, hiraditya, mgorny Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D69853
2019-11-05 12:00:49 +08:00
getOpenMPDirectiveName(Kind).data()))
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
return true;
bool IsCorrect = true;
OpenMP threadprivate with qualified names. llvm-svn: 181683
2013-05-13 12:18:18 +08:00
bool NoIdentIsFound = true;
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 14:34:35 +08:00
// Read tokens while ')' or annot_pragma_openmp_end is not found.
OpenMP threadprivate with qualified names. llvm-svn: 181683
2013-05-13 12:18:18 +08:00
while (Tok.isNot(tok::r_paren) && Tok.isNot(tok::annot_pragma_openmp_end)) {
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 14:34:35 +08:00
CXXScopeSpec SS;
UnqualifiedId Name;
// Read var name.
Token PrevTok = Tok;
OpenMP threadprivate with qualified names. llvm-svn: 181683
2013-05-13 12:18:18 +08:00
NoIdentIsFound = false;
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 14:34:35 +08:00
OpenMP threadprivate with qualified names. llvm-svn: 181683
2013-05-13 12:18:18 +08:00
if (AllowScopeSpecifier && getLangOpts().CPlusPlus &&
[Parser] Avoid spurious 'missing template' error in presence of typos. Suppress those diagnostics if lhs of a member expression contains errors. Typo correction produces dependent expressions even in non-template code, that led to spurious diagnostics before. previous: /tmp/t.cpp:6:17: error: use 'template' keyword to treat 'f' as a dependent template name auto a = bilder.f<int>(); ^ template /tmp/t.cpp:6:10: error: use of undeclared identifier 'bilder'; did you mean 'builder'? auto a = bilder.f<int>(); ^~~~~~ builder vs now: /tmp/t.cpp:6:10: error: use of undeclared identifier 'bilder'; did you mean 'builder'? auto a = bilder.f<int>(); ^~~~~~ builder Original patch from Ilya. Reviewers: sammccall Reviewed By: sammccall Tags: #clang Differential Revision: https://reviews.llvm.org/D65592
2020-03-19 16:12:29 +08:00
ParseOptionalCXXScopeSpecifier(SS, /*ObjectType=*/nullptr,
/*ObjectHadErrors=*/false, false)) {
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 14:34:35 +08:00
IsCorrect = false;
SkipUntil(tok::comma, tok::r_paren, tok::annot_pragma_openmp_end,
Revert "[OPENMP] Fix for parsing OpenMP directives with extra braces, brackets and parens" These parser changes were redundant. The same or better recovery can be achieved with a one-line fix to SkipUntil() due to land in the next commit. This reverts commit r197553. llvm-svn: 197597
2013-12-19 03:10:49 +08:00
StopBeforeMatch);
[Parser] Avoid spurious 'missing template' error in presence of typos. Suppress those diagnostics if lhs of a member expression contains errors. Typo correction produces dependent expressions even in non-template code, that led to spurious diagnostics before. previous: /tmp/t.cpp:6:17: error: use 'template' keyword to treat 'f' as a dependent template name auto a = bilder.f<int>(); ^ template /tmp/t.cpp:6:10: error: use of undeclared identifier 'bilder'; did you mean 'builder'? auto a = bilder.f<int>(); ^~~~~~ builder vs now: /tmp/t.cpp:6:10: error: use of undeclared identifier 'bilder'; did you mean 'builder'? auto a = bilder.f<int>(); ^~~~~~ builder Original patch from Ilya. Reviewers: sammccall Reviewed By: sammccall Tags: #clang Differential Revision: https://reviews.llvm.org/D65592
2020-03-19 16:12:29 +08:00
} else if (ParseUnqualifiedId(SS, /*ObjectType=*/nullptr,
/*ObjectHadErrors=*/false, false, false,
false, false, nullptr, Name)) {
OpenMP threadprivate with qualified names. llvm-svn: 181683
2013-05-13 12:18:18 +08:00
IsCorrect = false;
SkipUntil(tok::comma, tok::r_paren, tok::annot_pragma_openmp_end,
Revert "[OPENMP] Fix for parsing OpenMP directives with extra braces, brackets and parens" These parser changes were redundant. The same or better recovery can be achieved with a one-line fix to SkipUntil() due to land in the next commit. This reverts commit r197553. llvm-svn: 197597
2013-12-19 03:10:49 +08:00
StopBeforeMatch);
OpenMP threadprivate with qualified names. llvm-svn: 181683
2013-05-13 12:18:18 +08:00
} else if (Tok.isNot(tok::comma) && Tok.isNot(tok::r_paren) &&
Tok.isNot(tok::annot_pragma_openmp_end)) {
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 14:34:35 +08:00
IsCorrect = false;
SkipUntil(tok::comma, tok::r_paren, tok::annot_pragma_openmp_end,
Revert "[OPENMP] Fix for parsing OpenMP directives with extra braces, brackets and parens" These parser changes were redundant. The same or better recovery can be achieved with a one-line fix to SkipUntil() due to land in the next commit. This reverts commit r197553. llvm-svn: 197597
2013-12-19 03:10:49 +08:00
StopBeforeMatch);
Support and use token kinds as diagnostic arguments Introduce proper facilities to render token spellings using the diagnostic formatter. Replaces most of the hard-coded diagnostic messages related to expected tokens, which all shared the same semantics but had to be multiply defined due to variations in token order or quote marks. The associated parser changes are largely mechanical but they expose commonality in whole chunks of the parser that can now be factored away. This commit uses C++11 typed enums along with a speculative legacy fallback until the transition is complete. Requires corresponding changes in LLVM r197895. llvm-svn: 197972
2013-12-24 17:48:30 +08:00
Diag(PrevTok.getLocation(), diag::err_expected)
<< tok::identifier
<< SourceRange(PrevTok.getLocation(), PrevTokLocation);
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 14:34:35 +08:00
} else {
[OpenMP] Parse+Sema for '#pragma omp declare target' syntax version 4.5 Support OpenMP version 4.5 syntax for #pragma omp declare target. Syntax: #pragma omp declare target (extended-list) new-line or #pragma omp declare target clause[ [,] clause ... ] new-line Where clause is one of the following: to(extended-list) link(list) Differential Revision: http://reviews.llvm.org/D20011 llvm-svn: 268925
2016-05-09 22:59:13 +08:00
Callback(SS, Actions.GetNameFromUnqualifiedId(Name));
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 14:34:35 +08:00
}
// Consume ','.
if (Tok.is(tok::comma)) {
ConsumeToken();
}
OpenMP threadprivate with qualified names. llvm-svn: 181683
2013-05-13 12:18:18 +08:00
}
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 14:34:35 +08:00
OpenMP threadprivate with qualified names. llvm-svn: 181683
2013-05-13 12:18:18 +08:00
if (NoIdentIsFound) {
Support and use token kinds as diagnostic arguments Introduce proper facilities to render token spellings using the diagnostic formatter. Replaces most of the hard-coded diagnostic messages related to expected tokens, which all shared the same semantics but had to be multiply defined due to variations in token order or quote marks. The associated parser changes are largely mechanical but they expose commonality in whole chunks of the parser that can now be factored away. This commit uses C++11 typed enums along with a speculative legacy fallback until the transition is complete. Requires corresponding changes in LLVM r197895. llvm-svn: 197972
2013-12-24 17:48:30 +08:00
Diag(Tok, diag::err_expected) << tok::identifier;
OpenMP threadprivate with qualified names. llvm-svn: 181683
2013-05-13 12:18:18 +08:00
IsCorrect = false;
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 14:34:35 +08:00
}
OpenMP threadprivate with qualified names. llvm-svn: 181683
2013-05-13 12:18:18 +08:00
// Parse ')'.
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
IsCorrect = !T.consumeClose() && IsCorrect;
OpenMP threadprivate with qualified names. llvm-svn: 181683
2013-05-13 12:18:18 +08:00
[OpenMP] Parse+Sema for '#pragma omp declare target' syntax version 4.5 Support OpenMP version 4.5 syntax for #pragma omp declare target. Syntax: #pragma omp declare target (extended-list) new-line or #pragma omp declare target clause[ [,] clause ... ] new-line Where clause is one of the following: to(extended-list) link(list) Differential Revision: http://reviews.llvm.org/D20011 llvm-svn: 268925
2016-05-09 22:59:13 +08:00
return !IsCorrect;
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 14:34:35 +08:00
}
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
[OpenMP] Implement '#pragma omp tile', by Michael Kruse (@Meinersbur). The tile directive is in OpenMP's Technical Report 8 and foreseeably will be part of the upcoming OpenMP 5.1 standard. This implementation is based on an AST transformation providing a de-sugared loop nest. This makes it simple to forward the de-sugared transformation to loop associated directives taking the tiled loops. In contrast to other loop associated directives, the OMPTileDirective does not use CapturedStmts. Letting loop associated directives consume loops from different capture context would be difficult. A significant amount of code generation logic is taking place in the Sema class. Eventually, I would prefer if these would move into the CodeGen component such that we could make use of the OpenMPIRBuilder, together with flang. Only expressions converting between the language's iteration variable and the logical iteration space need to take place in the semantic analyzer: Getting the of iterations (e.g. the overload resolution of `std::distance`) and converting the logical iteration number to the iteration variable (e.g. overload resolution of `iteration + .omp.iv`). In clang, only CXXForRangeStmt is also represented by its de-sugared components. However, OpenMP loop are not defined as syntatic sugar. Starting with an AST-based approach allows us to gradually move generated AST statements into CodeGen, instead all at once. I would also like to refactor `checkOpenMPLoop` into its functionalities in a follow-up. In this patch it is used twice. Once for checking proper nesting and emitting diagnostics, and additionally for deriving the logical iteration space per-loop (instead of for the loop nest). Differential Revision: https://reviews.llvm.org/D76342
2021-02-13 03:26:59 +08:00
OMPClause *Parser::ParseOpenMPSizesClause() {
SourceLocation ClauseNameLoc = ConsumeToken();
SmallVector<Expr *, 4> ValExprs;
BalancedDelimiterTracker T(*this, tok::l_paren, tok::annot_pragma_openmp_end);
if (T.consumeOpen()) {
Diag(Tok, diag::err_expected) << tok::l_paren;
return nullptr;
}
while (true) {
ExprResult Val = ParseConstantExpression();
if (!Val.isUsable()) {
T.skipToEnd();
return nullptr;
}
ValExprs.push_back(Val.get());
if (Tok.is(tok::r_paren) || Tok.is(tok::annot_pragma_openmp_end))
break;
ExpectAndConsume(tok::comma);
}
T.consumeClose();
return Actions.ActOnOpenMPSizesClause(
ValExprs, ClauseNameLoc, T.getOpenLocation(), T.getCloseLocation());
}
[OPENMP50]Basic support for uses_allocators clause. Summary: Added parsing/sema/serialization supoprt for uses_allocators clause. Reviewers: jdoerfert Subscribers: yaxunl, guansong, arphaman, cfe-commits, caomhin Tags: #clang Differential Revision: https://reviews.llvm.org/D78577
2020-04-22 01:21:00 +08:00
OMPClause *Parser::ParseOpenMPUsesAllocatorClause(OpenMPDirectiveKind DKind) {
SourceLocation Loc = Tok.getLocation();
ConsumeAnyToken();
// Parse '('.
BalancedDelimiterTracker T(*this, tok::l_paren, tok::annot_pragma_openmp_end);
if (T.expectAndConsume(diag::err_expected_lparen_after, "uses_allocator"))
return nullptr;
SmallVector<Sema::UsesAllocatorsData, 4> Data;
do {
[OpenMP] Fix C-only clang assert on parsing use_allocator clause of target directive The parser code assumes building with C++ compiler and asserts when using clang (not clang++) on C file. I made the code dependent on input language. This shows up for amdgpu target. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D103899
2021-06-15 01:04:59 +08:00
ExprResult Allocator =
getLangOpts().CPlusPlus ? ParseCXXIdExpression() : ParseExpression();
[OPENMP50]Basic support for uses_allocators clause. Summary: Added parsing/sema/serialization supoprt for uses_allocators clause. Reviewers: jdoerfert Subscribers: yaxunl, guansong, arphaman, cfe-commits, caomhin Tags: #clang Differential Revision: https://reviews.llvm.org/D78577
2020-04-22 01:21:00 +08:00
if (Allocator.isInvalid()) {
SkipUntil(tok::comma, tok::r_paren, tok::annot_pragma_openmp_end,
StopBeforeMatch);
break;
}
Sema::UsesAllocatorsData &D = Data.emplace_back();
D.Allocator = Allocator.get();
if (Tok.is(tok::l_paren)) {
BalancedDelimiterTracker T(*this, tok::l_paren,
tok::annot_pragma_openmp_end);
T.consumeOpen();
[OpenMP] Fix C-only clang assert on parsing use_allocator clause of target directive The parser code assumes building with C++ compiler and asserts when using clang (not clang++) on C file. I made the code dependent on input language. This shows up for amdgpu target. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D103899
2021-06-15 01:04:59 +08:00
ExprResult AllocatorTraits =
getLangOpts().CPlusPlus ? ParseCXXIdExpression() : ParseExpression();
[OPENMP50]Basic support for uses_allocators clause. Summary: Added parsing/sema/serialization supoprt for uses_allocators clause. Reviewers: jdoerfert Subscribers: yaxunl, guansong, arphaman, cfe-commits, caomhin Tags: #clang Differential Revision: https://reviews.llvm.org/D78577
2020-04-22 01:21:00 +08:00
T.consumeClose();
if (AllocatorTraits.isInvalid()) {
SkipUntil(tok::comma, tok::r_paren, tok::annot_pragma_openmp_end,
StopBeforeMatch);
break;
}
D.AllocatorTraits = AllocatorTraits.get();
D.LParenLoc = T.getOpenLocation();
D.RParenLoc = T.getCloseLocation();
}
if (Tok.isNot(tok::comma) && Tok.isNot(tok::r_paren))
Diag(Tok, diag::err_omp_expected_punc) << "uses_allocators" << 0;
// Parse ','
if (Tok.is(tok::comma))
ConsumeAnyToken();
} while (Tok.isNot(tok::r_paren) && Tok.isNot(tok::annot_pragma_openmp_end));
T.consumeClose();
return Actions.ActOnOpenMPUsesAllocatorClause(Loc, T.getOpenLocation(),
T.getCloseLocation(), Data);
}
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Parsing of OpenMP clauses.
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
///
/// clause:
[OPENMP] Initial parsing and sema analysis for 'final' clause. llvm-svn: 213232
2014-07-17 15:32:53 +08:00
/// if-clause | final-clause | num_threads-clause | safelen-clause |
/// default-clause | private-clause | firstprivate-clause | shared-clause
/// | linear-clause | aligned-clause | collapse-clause |
/// lastprivate-clause | reduction-clause | proc_bind-clause |
[OPENMP] Initial parsing and sema analysis of 'mergeable' clause. llvm-svn: 213262
2014-07-17 20:47:03 +08:00
/// schedule-clause | copyin-clause | copyprivate-clause | untied-clause |
[OPENMP] Initial parsing and sema analysis for 'update' clause of 'atomic' directive. llvm-svn: 213735
2014-07-23 18:25:33 +08:00
/// mergeable-clause | flush-clause | read-clause | write-clause |
[OPENMP 4.1] Initial support for 'simdlen' clause. Add parsing/sema analysis for 'simdlen' clause in simd directives. Also add check that if both 'safelen' and 'simdlen' clauses are specified, the value of 'simdlen' parameter is less than the value of 'safelen' parameter. llvm-svn: 245692
2015-08-21 19:14:16 +08:00
/// update-clause | capture-clause | seq_cst-clause | device-clause |
[OpenMP] Parsing and sema support for thread_limit clause. http://reviews.llvm.org/D15029 llvm-svn: 254207
2015-11-28 02:47:36 +08:00
/// simdlen-clause | threads-clause | simd-clause | num_teams-clause |
[OPENMP 4.5] parsing/sema support for 'grainsize' clause. OpenMP 4.5 adds 'taksloop' and 'taskloop simd' directives, which have 'grainsize' clause. Patch adds parsing/sema analysis of this clause. llvm-svn: 254903
2015-12-07 20:52:51 +08:00
/// thread_limit-clause | priority-clause | grainsize-clause |
[OpenMP] Parsing and sema support for the from clause Summary: The patch contains the parsing and sema support for the `from` clause. Patch based on the original post by Kelvin Li. Reviewers: hfinkel, carlo.bertolli, kkwli0, arpith-jacob, ABataev Subscribers: caomhin, cfe-commits Differential Revision: http://reviews.llvm.org/D18488 llvm-svn: 270882
2016-05-27 01:49:04 +08:00
/// nogroup-clause | num_tasks-clause | hint-clause | to-clause |
[OPENMP] Initial support for 'in_reduction' clause. Parsing/sema analysis for 'in_reduction' clause for task-based directives. llvm-svn: 308768
2017-07-22 02:48:21 +08:00
/// from-clause | is_device_ptr-clause | task_reduction-clause |
[OPENMP50]Add parsing/sema for acq_rel clause. Added basic support (representation + parsing/sema/(de)serialization) for acq_rel clause in flush/atomic directives.
2020-02-07 05:30:23 +08:00
/// in_reduction-clause | allocator-clause | allocate-clause |
[OPENMP50]Add basic support for depobj construct. Added basic parsing/sema/serialization support for depobj directive.
2020-02-28 22:52:15 +08:00
/// acq_rel-clause | acquire-clause | release-clause | relaxed-clause |
[OPENMP50]Bassic support for exclusive clause. Added basic support (parsing/sema/serialization) for exclusive clause in scan directives.
2020-03-23 22:41:08 +08:00
/// depobj-clause | destroy-clause | detach-clause | inclusive-clause |
[OPENMP50]Initial support for use_device_addr clause. Summary: Added parsing/sema analysis/serialization support for use_device_addr clauses. Reviewers: jdoerfert Subscribers: yaxunl, guansong, arphaman, sstefan1, llvm-commits, cfe-commits, caomhin Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D80404
2020-05-21 20:30:23 +08:00
/// exclusive-clause | uses_allocators-clause | use_device_addr-clause
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
///
OMPClause *Parser::ParseOpenMPClause(OpenMPDirectiveKind DKind,
OpenMPClauseKind CKind, bool FirstClause) {
[OPENMP50] extend array section for stride (Parsing/Sema/AST) Reviewers: ABataev, jdoerfert Reviewed By: ABataev Subscribers: yaxunl, guansong, arphaman, sstefan1, cfe-commits, sandoval, dreachem Tags: #clang Differential Revision: https://reviews.llvm.org/D82800
2020-07-10 02:27:32 +08:00
OMPClauseKind = CKind;
[C++11] Use 'nullptr'. Parser edition. llvm-svn: 209275
2014-05-21 14:02:52 +08:00
OMPClause *Clause = nullptr;
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
bool ErrorFound = false;
[OpenMP] Fix handling of clause on wrong directive, by Joel. E. Denny Summary: First, this patch fixes an assert failure when, for example, "omp for" has num_teams. Second, this patch prevents duplicate diagnostics when, for example, "omp for" has uniform. This patch makes the general assumption (even where it doesn't necessarily fix an existing bug) that it is worthless to perform sema for a clause that appears on a directive on which OpenMP does not permit that clause. However, due to this assumption, this patch suppresses some diagnostics that were expected in the test suite. I assert that those diagnostics were likely just distracting to the user. Reviewers: ABataev Reviewed By: ABataev Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D41841 llvm-svn: 322107
2018-01-10 03:21:04 +08:00
bool WrongDirective = false;
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
// Check if clause is allowed for the given directive.
[OPENMP50]Add if clause in simd directive. According to OpenMP 5.0, if clause can be used in simd directive. If condition in the if clause if false, the non-vectorized version of the loop must be executed.
2019-11-20 01:07:54 +08:00
if (CKind != OMPC_unknown &&
!isAllowedClauseForDirective(DKind, CKind, getLangOpts().OpenMP)) {
[OpenMP][NFC] Clang format ParseOpenMP ParseOpenMP.cpp was pretty much clang-formatted except a few minor locations. Let's make it a clang formatted file. Reviewed By: JonChesterfield Differential Revision: https://reviews.llvm.org/D90440
2020-10-30 07:44:28 +08:00
Diag(Tok, diag::err_omp_unexpected_clause)
<< getOpenMPClauseName(CKind) << getOpenMPDirectiveName(DKind);
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
ErrorFound = true;
[OpenMP] Fix handling of clause on wrong directive, by Joel. E. Denny Summary: First, this patch fixes an assert failure when, for example, "omp for" has num_teams. Second, this patch prevents duplicate diagnostics when, for example, "omp for" has uniform. This patch makes the general assumption (even where it doesn't necessarily fix an existing bug) that it is worthless to perform sema for a clause that appears on a directive on which OpenMP does not permit that clause. However, due to this assumption, this patch suppresses some diagnostics that were expected in the test suite. I assert that those diagnostics were likely just distracting to the user. Reviewers: ABataev Reviewed By: ABataev Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D41841 llvm-svn: 322107
2018-01-10 03:21:04 +08:00
WrongDirective = true;
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
}
switch (CKind) {
[OPENMP] Initial parsing and sema analysis for 'final' clause. llvm-svn: 213232
2014-07-17 15:32:53 +08:00
case OMPC_final:
[OPENMP] Clause 'num_threads' llvm-svn: 203087
2014-03-06 14:15:19 +08:00
case OMPC_num_threads:
[OPENMP] parsing of clause 'safelen' (for directive 'omp simd') llvm-svn: 204428
2014-03-21 12:51:18 +08:00
case OMPC_safelen:
[OPENMP 4.1] Initial support for 'simdlen' clause. Add parsing/sema analysis for 'simdlen' clause in simd directives. Also add check that if both 'safelen' and 'simdlen' clauses are specified, the value of 'simdlen' parameter is less than the value of 'safelen' parameter. llvm-svn: 245692
2015-08-21 19:14:16 +08:00
case OMPC_simdlen:
Parsing/Sema for OMPCollapseClause. Actual usage in Sema for collapsing loops will in some future patch. llvm-svn: 209660
2014-05-27 23:12:19 +08:00
case OMPC_collapse:
[OPENMP 4.1] Initial support for extended 'ordered' clause. OpenMP 4.1 introduces optional argument '(n)' for 'ordered' clause, where 'n' is a number of loops that immediately follow the directive. 'n' must be constant positive integer expressions and it must be less or equal than the number of the loops in the resulting loop nest. Patch adds parsing and semantic analysis for this optional argument. llvm-svn: 243635
2015-07-30 19:36:16 +08:00
case OMPC_ordered:
[OpenMP] Parsing and sema support for num_teams clause http://reviews.llvm.org/D14802 llvm-svn: 254019
2015-11-25 04:50:12 +08:00
case OMPC_num_teams:
[OpenMP] Parsing and sema support for thread_limit clause. http://reviews.llvm.org/D15029 llvm-svn: 254207
2015-11-28 02:47:36 +08:00
case OMPC_thread_limit:
[OPENMP 4.5] Parsing/sema analysis for 'priority' clause. OpenMP 4.5 defines new clause 'priority' for 'task', 'taskloop' and 'taskloop simd' directives. Added parsing and sema analysis for 'priority' clause in 'task' and 'taskloop' directives. llvm-svn: 254398
2015-12-01 18:17:31 +08:00
case OMPC_priority:
[OPENMP 4.5] parsing/sema support for 'grainsize' clause. OpenMP 4.5 adds 'taksloop' and 'taskloop simd' directives, which have 'grainsize' clause. Patch adds parsing/sema analysis of this clause. llvm-svn: 254903
2015-12-07 20:52:51 +08:00
case OMPC_grainsize:
[OPENMP 4.5] Parsing/sema for 'num_tasks' clause. OpenMP 4.5 adds directives 'taskloop' and 'taskloop simd'. These directives support clause 'num_tasks'. Patch adds parsing/semantic analysis for this clause. llvm-svn: 255008
2015-12-08 20:06:20 +08:00
case OMPC_num_tasks:
[OPENMP 4.5] Parsing/sema for 'hint' clause of 'critical' directive. OpenMP 4.5 adds 'hint' clause to critical directive. Patch adds parsing/semantic analysis for this clause. llvm-svn: 255625
2015-12-15 16:19:24 +08:00
case OMPC_hint:
[OPENMP 5.0]Initial support for 'allocator' clause. Added parsing/sema analysis/serialization/deserialization for the 'allocator' clause of the 'allocate' directive. llvm-svn: 355952
2019-03-13 02:52:33 +08:00
case OMPC_allocator:
[OPENMP50]Add basic support for depobj construct. Added basic parsing/sema/serialization support for depobj directive.
2020-02-28 22:52:15 +08:00
case OMPC_depobj:
[OPENMP50]Initial support for detach clause in task directive. Added parsing/sema/serialization support for detach clause.
2020-03-17 21:17:42 +08:00
case OMPC_detach:
[OPENMP5.1]Initial support for novariants clause. Added basic parsing/sema/serialization support for the 'novariants' clause.
2021-04-01 03:26:47 +08:00
case OMPC_novariants:
[OPENMP51]Initial support for nocontext clause. Added basic parsing/sema/serialization support for the 'nocontext' clause. Differential Revision: https://reviews.llvm.org/D99848
2021-04-04 02:09:25 +08:00
case OMPC_nocontext:
[OpenMP51] Initial support for masked directive and filter clause Adds basic parsing/sema/serialization support for the #pragma omp masked directive. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D99995
2021-04-10 03:00:36 +08:00
case OMPC_filter:
[OpenMP] Implement '#pragma omp unroll'. Implementation of the unroll directive introduced in OpenMP 5.1. Follows the approach from D76342 for the tile directive (i.e. AST-based, not using the OpenMPIRBuilder). Tries to use `llvm.loop.unroll.*` metadata where possible, but has to fall back to an AST representation of the outer loop if the partially unrolled generated loop is associated with another directive (because it needs to compute the number of iterations). Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D99459
2021-06-11 03:24:17 +08:00
case OMPC_partial:
[OPENMP] 'if' clause support (no CodeGen support) llvm-svn: 201297
2014-02-13 13:29:23 +08:00
// OpenMP [2.5, Restrictions]
[OPENMP] Clause 'num_threads' llvm-svn: 203087
2014-03-06 14:15:19 +08:00
// At most one num_threads clause can appear on the directive.
[OPENMP] parsing of clause 'safelen' (for directive 'omp simd') llvm-svn: 204428
2014-03-21 12:51:18 +08:00
// OpenMP [2.8.1, simd construct, Restrictions]
Parsing/Sema for OMPCollapseClause. Actual usage in Sema for collapsing loops will in some future patch. llvm-svn: 209660
2014-05-27 23:12:19 +08:00
// Only one safelen clause can appear on a simd directive.
[OPENMP 4.1] Initial support for 'simdlen' clause. Add parsing/sema analysis for 'simdlen' clause in simd directives. Also add check that if both 'safelen' and 'simdlen' clauses are specified, the value of 'simdlen' parameter is less than the value of 'safelen' parameter. llvm-svn: 245692
2015-08-21 19:14:16 +08:00
// Only one simdlen clause can appear on a simd directive.
Parsing/Sema for OMPCollapseClause. Actual usage in Sema for collapsing loops will in some future patch. llvm-svn: 209660
2014-05-27 23:12:19 +08:00
// Only one collapse clause can appear on a simd directive.
[OPENMP] Initial parsing and sema analysis for 'final' clause. llvm-svn: 213232
2014-07-17 15:32:53 +08:00
// OpenMP [2.11.1, task Construct, Restrictions]
// At most one if clause can appear on the directive.
// At most one final clause can appear on the directive.
[OpenMP] Parsing and sema support for num_teams clause http://reviews.llvm.org/D14802 llvm-svn: 254019
2015-11-25 04:50:12 +08:00
// OpenMP [teams Construct, Restrictions]
// At most one num_teams clause can appear on the directive.
[OpenMP] Parsing and sema support for thread_limit clause. http://reviews.llvm.org/D15029 llvm-svn: 254207
2015-11-28 02:47:36 +08:00
// At most one thread_limit clause can appear on the directive.
[OPENMP 4.5] Parsing/sema analysis for 'priority' clause. OpenMP 4.5 defines new clause 'priority' for 'task', 'taskloop' and 'taskloop simd' directives. Added parsing and sema analysis for 'priority' clause in 'task' and 'taskloop' directives. llvm-svn: 254398
2015-12-01 18:17:31 +08:00
// OpenMP [2.9.1, task Construct, Restrictions]
// At most one priority clause can appear on the directive.
[OPENMP 4.5] parsing/sema support for 'grainsize' clause. OpenMP 4.5 adds 'taksloop' and 'taskloop simd' directives, which have 'grainsize' clause. Patch adds parsing/sema analysis of this clause. llvm-svn: 254903
2015-12-07 20:52:51 +08:00
// OpenMP [2.9.2, taskloop Construct, Restrictions]
// At most one grainsize clause can appear on the directive.
[OPENMP 4.5] Parsing/sema for 'num_tasks' clause. OpenMP 4.5 adds directives 'taskloop' and 'taskloop simd'. These directives support clause 'num_tasks'. Patch adds parsing/semantic analysis for this clause. llvm-svn: 255008
2015-12-08 20:06:20 +08:00
// OpenMP [2.9.2, taskloop Construct, Restrictions]
// At most one num_tasks clause can appear on the directive.
[OPENMP 5.0]Initial support for 'allocator' clause. Added parsing/sema analysis/serialization/deserialization for the 'allocator' clause of the 'allocate' directive. llvm-svn: 355952
2019-03-13 02:52:33 +08:00
// OpenMP [2.11.3, allocate Directive, Restrictions]
// At most one allocator clause can appear on the directive.
[OPENMP50]Initial support for detach clause in task directive. Added parsing/sema/serialization support for detach clause.
2020-03-17 21:17:42 +08:00
// OpenMP 5.0, 2.10.1 task Construct, Restrictions.
// At most one detach clause can appear on the directive.
[OPENMP5.1]Initial support for novariants clause. Added basic parsing/sema/serialization support for the 'novariants' clause.
2021-04-01 03:26:47 +08:00
// OpenMP 5.1, 2.3.6 dispatch Construct, Restrictions.
// At most one novariants clause can appear on a dispatch directive.
[OPENMP51]Initial support for nocontext clause. Added basic parsing/sema/serialization support for the 'nocontext' clause. Differential Revision: https://reviews.llvm.org/D99848
2021-04-04 02:09:25 +08:00
// At most one nocontext clause can appear on a dispatch directive.
[OPENMP] 'if' clause support (no CodeGen support) llvm-svn: 201297
2014-02-13 13:29:23 +08:00
if (!FirstClause) {
[OPENMP 4.1] Parsing/sema analysis for extended format of 'if' clause. OpenMP 4.1 added special 'directive-name-modifier' to the 'if' clause. Format of 'if' clause is as follows: ``` if([ directive-name-modifier :] scalar-logical-expression) ``` The restriction rules are also changed. 1. If any 'if' clause on the directive includes a 'directive-name-modifier' then all 'if' clauses on the directive must include a 'directive-name-modifier'. 2. At most one 'if' clause without a 'directive-name-modifier' can appear on the directive. 3. At most one 'if' clause with some particular 'directive-name-modifier' can appear on the directive. 'directive-name-modifier' is important for combined directives and allows to separate conditions in 'if' clause for simple sub-directives in combined directive. This 'directive-name-modifier' identifies the sub-directive to which this 'if' clause must be applied. llvm-svn: 246747
2015-09-03 15:23:48 +08:00
Diag(Tok, diag::err_omp_more_one_clause)
<< getOpenMPDirectiveName(DKind) << getOpenMPClauseName(CKind) << 0;
[OPENMP] Initial parsing an sema analysis for 'write' clause of 'atomic' directive. llvm-svn: 213728
2014-07-23 15:46:59 +08:00
ErrorFound = true;
[OPENMP] 'if' clause support (no CodeGen support) llvm-svn: 201297
2014-02-13 13:29:23 +08:00
}
[OpenMP] Implement '#pragma omp unroll'. Implementation of the unroll directive introduced in OpenMP 5.1. Follows the approach from D76342 for the tile directive (i.e. AST-based, not using the OpenMPIRBuilder). Tries to use `llvm.loop.unroll.*` metadata where possible, but has to fall back to an AST representation of the outer loop if the partially unrolled generated loop is associated with another directive (because it needs to compute the number of iterations). Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D99459
2021-06-11 03:24:17 +08:00
if ((CKind == OMPC_ordered || CKind == OMPC_partial) &&
PP.LookAhead(/*N=*/0).isNot(tok::l_paren))
[OpenMP] Fix handling of clause on wrong directive, by Joel. E. Denny Summary: First, this patch fixes an assert failure when, for example, "omp for" has num_teams. Second, this patch prevents duplicate diagnostics when, for example, "omp for" has uniform. This patch makes the general assumption (even where it doesn't necessarily fix an existing bug) that it is worthless to perform sema for a clause that appears on a directive on which OpenMP does not permit that clause. However, due to this assumption, this patch suppresses some diagnostics that were expected in the test suite. I assert that those diagnostics were likely just distracting to the user. Reviewers: ABataev Reviewed By: ABataev Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D41841 llvm-svn: 322107
2018-01-10 03:21:04 +08:00
Clause = ParseOpenMPClause(CKind, WrongDirective);
[OPENMP 4.1] Initial support for extended 'ordered' clause. OpenMP 4.1 introduces optional argument '(n)' for 'ordered' clause, where 'n' is a number of loops that immediately follow the directive. 'n' must be constant positive integer expressions and it must be less or equal than the number of the loops in the resulting loop nest. Patch adds parsing and semantic analysis for this optional argument. llvm-svn: 243635
2015-07-30 19:36:16 +08:00
else
[OpenMP] Fix handling of clause on wrong directive, by Joel. E. Denny Summary: First, this patch fixes an assert failure when, for example, "omp for" has num_teams. Second, this patch prevents duplicate diagnostics when, for example, "omp for" has uniform. This patch makes the general assumption (even where it doesn't necessarily fix an existing bug) that it is worthless to perform sema for a clause that appears on a directive on which OpenMP does not permit that clause. However, due to this assumption, this patch suppresses some diagnostics that were expected in the test suite. I assert that those diagnostics were likely just distracting to the user. Reviewers: ABataev Reviewed By: ABataev Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D41841 llvm-svn: 322107
2018-01-10 03:21:04 +08:00
Clause = ParseOpenMPSingleExprClause(CKind, WrongDirective);
[OPENMP] 'if' clause support (no CodeGen support) llvm-svn: 201297
2014-02-13 13:29:23 +08:00
break;
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
case OMPC_default:
[OPENMP] 'proc_bind' clause support - Parsing and sema analysis for OpenMP clause 'proc_bind' llvm-svn: 208060
2014-05-06 14:04:14 +08:00
case OMPC_proc_bind:
Add support for 'atomic_default_mem_order' clause on 'requires' directive. Also renamed test files relating to 'requires'. Differntial review: https://reviews.llvm.org/D53513 llvm-svn: 345967
2018-11-02 20:18:11 +08:00
case OMPC_atomic_default_mem_order:
[OPENMP50]Basic parsing/sema analysis for order(concurrent) clause. Added parsing/sema/serialization support for order(concurrent) clause in loop|simd-based directives.
2020-02-01 05:09:26 +08:00
case OMPC_order:
[OPENMP] 'if' clause support (no CodeGen support) llvm-svn: 201297
2014-02-13 13:29:23 +08:00
// OpenMP [2.14.3.1, Restrictions]
// Only a single default clause may be specified on a parallel, task or
// teams directive.
[OPENMP] 'proc_bind' clause support - Parsing and sema analysis for OpenMP clause 'proc_bind' llvm-svn: 208060
2014-05-06 14:04:14 +08:00
// OpenMP [2.5, parallel Construct, Restrictions]
// At most one proc_bind clause can appear on the directive.
Add support for 'atomic_default_mem_order' clause on 'requires' directive. Also renamed test files relating to 'requires'. Differntial review: https://reviews.llvm.org/D53513 llvm-svn: 345967
2018-11-02 20:18:11 +08:00
// OpenMP [5.0, Requires directive, Restrictions]
// At most one atomic_default_mem_order clause can appear
// on the directive
[OPENMP50]Basic parsing/sema analysis for order(concurrent) clause. Added parsing/sema/serialization support for order(concurrent) clause in loop|simd-based directives.
2020-02-01 05:09:26 +08:00
if (!FirstClause && CKind != OMPC_order) {
[OPENMP 4.1] Parsing/sema analysis for extended format of 'if' clause. OpenMP 4.1 added special 'directive-name-modifier' to the 'if' clause. Format of 'if' clause is as follows: ``` if([ directive-name-modifier :] scalar-logical-expression) ``` The restriction rules are also changed. 1. If any 'if' clause on the directive includes a 'directive-name-modifier' then all 'if' clauses on the directive must include a 'directive-name-modifier'. 2. At most one 'if' clause without a 'directive-name-modifier' can appear on the directive. 3. At most one 'if' clause with some particular 'directive-name-modifier' can appear on the directive. 'directive-name-modifier' is important for combined directives and allows to separate conditions in 'if' clause for simple sub-directives in combined directive. This 'directive-name-modifier' identifies the sub-directive to which this 'if' clause must be applied. llvm-svn: 246747
2015-09-03 15:23:48 +08:00
Diag(Tok, diag::err_omp_more_one_clause)
<< getOpenMPDirectiveName(DKind) << getOpenMPClauseName(CKind) << 0;
[OPENMP] Initial parsing an sema analysis for 'write' clause of 'atomic' directive. llvm-svn: 213728
2014-07-23 15:46:59 +08:00
ErrorFound = true;
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
}
[OpenMP] Fix handling of clause on wrong directive, by Joel. E. Denny Summary: First, this patch fixes an assert failure when, for example, "omp for" has num_teams. Second, this patch prevents duplicate diagnostics when, for example, "omp for" has uniform. This patch makes the general assumption (even where it doesn't necessarily fix an existing bug) that it is worthless to perform sema for a clause that appears on a directive on which OpenMP does not permit that clause. However, due to this assumption, this patch suppresses some diagnostics that were expected in the test suite. I assert that those diagnostics were likely just distracting to the user. Reviewers: ABataev Reviewed By: ABataev Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D41841 llvm-svn: 322107
2018-01-10 03:21:04 +08:00
Clause = ParseOpenMPSimpleClause(CKind, WrongDirective);
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
break;
[OPENMP50]Add support for extended device clause in target directives. Added parsing/sema/serialization support for extended device clause in executable target directives.
2020-03-19 03:01:15 +08:00
case OMPC_device:
[OPENMP] Initial support for 'schedule' clause. llvm-svn: 211342
2014-06-20 15:16:17 +08:00
case OMPC_schedule:
Add OpenMP dist_schedule clause to distribute directive and related regression tests. llvm-svn: 257917
2016-01-16 02:50:31 +08:00
case OMPC_dist_schedule:
[OpenMP] Parsing + sema for defaultmap clause. Summary: This patch adds parsing + sema for the defaultmap clause associated with the target directive (among others). Reviewers: ABataev Differential Revision: http://reviews.llvm.org/D16527 llvm-svn: 258817
2016-01-27 00:37:23 +08:00
case OMPC_defaultmap:
[OPENMP] Initial support for 'schedule' clause. llvm-svn: 211342
2014-06-20 15:16:17 +08:00
// OpenMP [2.7.1, Restrictions, p. 3]
// Only one schedule clause can appear on a loop directive.
[OpenMP 5.0] - Extend defaultmap, by Chi Chun Chen. Summary: For the extended defaultmap, most of the work is inside sema. The only difference for codegen is to set different initial maptype for different implicit-behavior. Reviewers: jdoerfert, ABataev Reviewed By: ABataev Subscribers: dreachem, sandoval, cfe-commits Tags: #clang, #openmp Differential Revision: https://reviews.llvm.org/D69204
2019-11-16 02:02:06 +08:00
// OpenMP 4.5 [2.10.4, Restrictions, p. 106]
[OpenMP] Parsing + sema for defaultmap clause. Summary: This patch adds parsing + sema for the defaultmap clause associated with the target directive (among others). Reviewers: ABataev Differential Revision: http://reviews.llvm.org/D16527 llvm-svn: 258817
2016-01-27 00:37:23 +08:00
// At most one defaultmap clause can appear on the directive.
[OPENMP50]Add support for extended device clause in target directives. Added parsing/sema/serialization support for extended device clause in executable target directives.
2020-03-19 03:01:15 +08:00
// OpenMP 5.0 [2.12.5, target construct, Restrictions]
// At most one device clause can appear on the directive.
[OpenMP 5.0] - Extend defaultmap, by Chi Chun Chen. Summary: For the extended defaultmap, most of the work is inside sema. The only difference for codegen is to set different initial maptype for different implicit-behavior. Reviewers: jdoerfert, ABataev Reviewed By: ABataev Subscribers: dreachem, sandoval, cfe-commits Tags: #clang, #openmp Differential Revision: https://reviews.llvm.org/D69204
2019-11-16 02:02:06 +08:00
if ((getLangOpts().OpenMP < 50 || CKind != OMPC_defaultmap) &&
!FirstClause) {
[OPENMP 4.1] Parsing/sema analysis for extended format of 'if' clause. OpenMP 4.1 added special 'directive-name-modifier' to the 'if' clause. Format of 'if' clause is as follows: ``` if([ directive-name-modifier :] scalar-logical-expression) ``` The restriction rules are also changed. 1. If any 'if' clause on the directive includes a 'directive-name-modifier' then all 'if' clauses on the directive must include a 'directive-name-modifier'. 2. At most one 'if' clause without a 'directive-name-modifier' can appear on the directive. 3. At most one 'if' clause with some particular 'directive-name-modifier' can appear on the directive. 'directive-name-modifier' is important for combined directives and allows to separate conditions in 'if' clause for simple sub-directives in combined directive. This 'directive-name-modifier' identifies the sub-directive to which this 'if' clause must be applied. llvm-svn: 246747
2015-09-03 15:23:48 +08:00
Diag(Tok, diag::err_omp_more_one_clause)
<< getOpenMPDirectiveName(DKind) << getOpenMPClauseName(CKind) << 0;
[OPENMP] Initial parsing an sema analysis for 'write' clause of 'atomic' directive. llvm-svn: 213728
2014-07-23 15:46:59 +08:00
ErrorFound = true;
[OPENMP] Initial support for 'schedule' clause. llvm-svn: 211342
2014-06-20 15:16:17 +08:00
}
Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC. llvm-svn: 304478
2017-06-02 05:26:38 +08:00
LLVM_FALLTHROUGH;
[OPENMP 4.1] Parsing/sema analysis for extended format of 'if' clause. OpenMP 4.1 added special 'directive-name-modifier' to the 'if' clause. Format of 'if' clause is as follows: ``` if([ directive-name-modifier :] scalar-logical-expression) ``` The restriction rules are also changed. 1. If any 'if' clause on the directive includes a 'directive-name-modifier' then all 'if' clauses on the directive must include a 'directive-name-modifier'. 2. At most one 'if' clause without a 'directive-name-modifier' can appear on the directive. 3. At most one 'if' clause with some particular 'directive-name-modifier' can appear on the directive. 'directive-name-modifier' is important for combined directives and allows to separate conditions in 'if' clause for simple sub-directives in combined directive. This 'directive-name-modifier' identifies the sub-directive to which this 'if' clause must be applied. llvm-svn: 246747
2015-09-03 15:23:48 +08:00
case OMPC_if:
[OPENMP50]Add support for extended device clause in target directives. Added parsing/sema/serialization support for extended device clause in executable target directives.
2020-03-19 03:01:15 +08:00
Clause = ParseOpenMPSingleExprWithArgClause(DKind, CKind, WrongDirective);
[OPENMP] Initial support for 'schedule' clause. llvm-svn: 211342
2014-06-20 15:16:17 +08:00
break;
[OPENMP] Initial support for 'nowait' clause. llvm-svn: 211352
2014-06-20 19:19:47 +08:00
case OMPC_nowait:
[OPENMP] Initial support for parsing and sema analysis of 'untied' clause. llvm-svn: 213257
2014-07-17 20:19:31 +08:00
case OMPC_untied:
[OPENMP] Initial parsing and sema analysis of 'mergeable' clause. llvm-svn: 213262
2014-07-17 20:47:03 +08:00
case OMPC_mergeable:
[OPENMP] Initial parsing and sema analysis for 'read' clause in 'atomic' directive. llvm-svn: 213717
2014-07-23 10:27:21 +08:00
case OMPC_read:
[OPENMP] Initial parsing an sema analysis for 'write' clause of 'atomic' directive. llvm-svn: 213728
2014-07-23 15:46:59 +08:00
case OMPC_write:
[OPENMP] Initial parsing and sema analysis for clause 'capture' in 'atomic' directive. llvm-svn: 213842
2014-07-24 14:46:57 +08:00
case OMPC_capture:
[OPENMP] Initial parsing and sema analysis for clause 'seq_cst' of 'atomic' directive. llvm-svn: 213846
2014-07-24 16:55:34 +08:00
case OMPC_seq_cst:
[OPENMP50]Add parsing/sema for acq_rel clause. Added basic support (representation + parsing/sema/(de)serialization) for acq_rel clause in flush/atomic directives.
2020-02-07 05:30:23 +08:00
case OMPC_acq_rel:
[OPENMP50]Support for acquire clause. Added full support for acquire clause in flush|atomic directives.
2020-02-11 03:30:39 +08:00
case OMPC_acquire:
[OPENMP50]Add support for 'release' clause. Added full support for 'release' clause in flush|atomic directives.
2020-02-11 04:49:05 +08:00
case OMPC_release:
[OPENMP50]Add support for relaxed clause in atomic directive. Added full support for relaxed clause.
2020-02-12 00:10:43 +08:00
case OMPC_relaxed:
[OPENMP 4.1] Add 'threads' clause for '#pragma omp ordered'. OpenMP 4.1 extends format of '#pragma omp ordered'. It adds 3 additional clauses: 'threads', 'simd' and 'depend'. If no clause is specified, the ordered construct behaves as if the threads clause had been specified. If the threads clause is specified, the threads in the team executing the loop region execute ordered regions sequentially in the order of the loop iterations. The loop region to which an ordered region without any clause or with a threads clause binds must have an ordered clause without the parameter specified on the corresponding loop directive. llvm-svn: 248569
2015-09-25 18:37:12 +08:00
case OMPC_threads:
[OPENMP 4.1] Add 'simd' clause for 'ordered' directive. Parsing and sema analysis for 'simd' clause in 'ordered' directive. Description If the simd clause is specified, the ordered regions encountered by any thread will use only a single SIMD lane to execute the ordered regions in the order of the loop iterations. Restrictions An ordered construct with the simd clause is the only OpenMP construct that can appear in the simd region llvm-svn: 248696
2015-09-28 14:39:35 +08:00
case OMPC_simd:
[OPENMP 4.5] parsing/sema support for 'nogroup' clause. OpenMP 4.5 adds 'taskloop' and 'taskloop simd' directives. These directives have new 'nogroup' clause. Patch adds basic parsing/sema support for this clause. llvm-svn: 254899
2015-12-07 18:51:44 +08:00
case OMPC_nogroup:
[OPENMP] Add support for OMP5 requires directive + unified_address clause Add support for OMP5.0 requires directive and unified_address clause. Patches to follow will include support for additional clauses. Differential Revision: https://reviews.llvm.org/D52359 llvm-svn: 343063
2018-09-26 12:28:39 +08:00
case OMPC_unified_address:
Add support for unified_shared_memory clause on requires directive llvm-svn: 343472
2018-10-01 21:47:43 +08:00
case OMPC_unified_shared_memory:
[OPENMP] Add reverse_offload clause to requires directive llvm-svn: 343711
2018-10-04 04:07:58 +08:00
case OMPC_reverse_offload:
Add support for 'dynamic_allocators' clause on 'requires' directive. Differential Revision: https://reviews.llvm.org/D53079 llvm-svn: 344249
2018-10-11 22:41:10 +08:00
case OMPC_dynamic_allocators:
[OpenMP] Implement '#pragma omp unroll'. Implementation of the unroll directive introduced in OpenMP 5.1. Follows the approach from D76342 for the tile directive (i.e. AST-based, not using the OpenMPIRBuilder). Tries to use `llvm.loop.unroll.*` metadata where possible, but has to fall back to an AST representation of the outer loop if the partially unrolled generated loop is associated with another directive (because it needs to compute the number of iterations). Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D99459
2021-06-11 03:24:17 +08:00
case OMPC_full:
[OPENMP] Initial support for 'ordered' clause. llvm-svn: 211347
2014-06-20 17:44:06 +08:00
// OpenMP [2.7.1, Restrictions, p. 9]
// Only one ordered clause can appear on a loop directive.
[OPENMP] Initial support for 'nowait' clause. llvm-svn: 211352
2014-06-20 19:19:47 +08:00
// OpenMP [2.7.1, Restrictions, C/C++, p. 4]
// Only one nowait clause can appear on a for directive.
[OPENMP] Add support for OMP5 requires directive + unified_address clause Add support for OMP5.0 requires directive and unified_address clause. Patches to follow will include support for additional clauses. Differential Revision: https://reviews.llvm.org/D52359 llvm-svn: 343063
2018-09-26 12:28:39 +08:00
// OpenMP [5.0, Requires directive, Restrictions]
// Each of the requires clauses can appear at most once on the directive.
[OPENMP] Initial support for 'ordered' clause. llvm-svn: 211347
2014-06-20 17:44:06 +08:00
if (!FirstClause) {
[OPENMP 4.1] Parsing/sema analysis for extended format of 'if' clause. OpenMP 4.1 added special 'directive-name-modifier' to the 'if' clause. Format of 'if' clause is as follows: ``` if([ directive-name-modifier :] scalar-logical-expression) ``` The restriction rules are also changed. 1. If any 'if' clause on the directive includes a 'directive-name-modifier' then all 'if' clauses on the directive must include a 'directive-name-modifier'. 2. At most one 'if' clause without a 'directive-name-modifier' can appear on the directive. 3. At most one 'if' clause with some particular 'directive-name-modifier' can appear on the directive. 'directive-name-modifier' is important for combined directives and allows to separate conditions in 'if' clause for simple sub-directives in combined directive. This 'directive-name-modifier' identifies the sub-directive to which this 'if' clause must be applied. llvm-svn: 246747
2015-09-03 15:23:48 +08:00
Diag(Tok, diag::err_omp_more_one_clause)
<< getOpenMPDirectiveName(DKind) << getOpenMPClauseName(CKind) << 0;
[OPENMP] Initial parsing an sema analysis for 'write' clause of 'atomic' directive. llvm-svn: 213728
2014-07-23 15:46:59 +08:00
ErrorFound = true;
[OPENMP] Initial support for 'ordered' clause. llvm-svn: 211347
2014-06-20 17:44:06 +08:00
}
[OpenMP] Fix handling of clause on wrong directive, by Joel. E. Denny Summary: First, this patch fixes an assert failure when, for example, "omp for" has num_teams. Second, this patch prevents duplicate diagnostics when, for example, "omp for" has uniform. This patch makes the general assumption (even where it doesn't necessarily fix an existing bug) that it is worthless to perform sema for a clause that appears on a directive on which OpenMP does not permit that clause. However, due to this assumption, this patch suppresses some diagnostics that were expected in the test suite. I assert that those diagnostics were likely just distracting to the user. Reviewers: ABataev Reviewed By: ABataev Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D41841 llvm-svn: 322107
2018-01-10 03:21:04 +08:00
Clause = ParseOpenMPClause(CKind, WrongDirective);
[OPENMP] Initial support for 'ordered' clause. llvm-svn: 211347
2014-06-20 17:44:06 +08:00
break;
[OPENMP50]Support 'update' clause for 'depobj' directive. Added basic support (parsing/sema/serialization) for 'update' clause in 'depobj' directive.
2020-03-04 02:22:35 +08:00
case OMPC_update:
if (!FirstClause) {
Diag(Tok, diag::err_omp_more_one_clause)
<< getOpenMPDirectiveName(DKind) << getOpenMPClauseName(CKind) << 0;
ErrorFound = true;
}
Clause = (DKind == OMPD_depobj)
? ParseOpenMPSimpleClause(CKind, WrongDirective)
: ParseOpenMPClause(CKind, WrongDirective);
break;
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
case OMPC_private:
[OpenMP] Added parsing and semantic analysis for firstprivate clause llvm-svn: 191730
2013-10-01 13:32:34 +08:00
case OMPC_firstprivate:
[OPENMP] Parsing/Sema for OMPLasprivateClause. Parsing this clause, allowing it on directive ‘omp simd’ and semantic checks. llvm-svn: 210184
2014-06-04 21:06:39 +08:00
case OMPC_lastprivate:
OpenMP: Data-sharing attributes analysis and clause 'shared' (fixed test threadprivate_messages.cpp) llvm-svn: 190183
2013-09-07 02:03:48 +08:00
case OMPC_shared:
[OPENMP] Initial support of 'reduction' clause llvm-svn: 211007
2014-06-16 15:08:35 +08:00
case OMPC_reduction:
[OPENMP] Initial support for 'task_reduction' clause. Parsing/sema analysis of the 'task_reduction' clause. llvm-svn: 308352
2017-07-19 04:17:46 +08:00
case OMPC_task_reduction:
[OPENMP] Initial support for 'in_reduction' clause. Parsing/sema analysis for 'in_reduction' clause for task-based directives. llvm-svn: 308768
2017-07-22 02:48:21 +08:00
case OMPC_in_reduction:
[OPENMP] parsing 'linear' clause (for directive 'omp simd') Differential Revision: http://reviews.llvm.org/D3272 llvm-svn: 206891
2014-04-22 21:09:42 +08:00
case OMPC_linear:
Parsing/Sema for OMPAlignedClause. llvm-svn: 209816
2014-05-29 22:36:25 +08:00
case OMPC_aligned:
[OPENMP] Implemented 'copyin' clause llvm-svn: 205164
2014-03-31 11:36:38 +08:00
case OMPC_copyin:
[OPENMP] Parsing and sema analysis for 'copyprivate' clause. llvm-svn: 211886
2014-06-27 18:37:06 +08:00
case OMPC_copyprivate:
[OPENMP] Initial parsing and sema analysis for 'flush' directive. llvm-svn: 213512
2014-07-21 19:26:11 +08:00
case OMPC_flush:
[OPENMP] Initial support for 'depend' clause (4.0). Parsing and sema analysis (without support for array sections in arguments) for 'depend' clause (used in 'task' directive, OpenMP 4.0). llvm-svn: 240409
2015-06-23 22:25:19 +08:00
case OMPC_depend:
[OpenMP] Parsing and sema support for map clause http://reviews.llvm.org/D14134 llvm-svn: 253849
2015-11-23 13:32:03 +08:00
case OMPC_map:
[OpenMP] Parsing and sema support for the to clause Summary: The patch contains the parsing and sema support for the `to` clause. Patch based on the original post by Kelvin Li. Reviewers: carlo.bertolli, hfinkel, kkwli0, arpith-jacob, ABataev Subscribers: caomhin, cfe-commits Differential Revision: http://reviews.llvm.org/D18597 llvm-svn: 270880
2016-05-27 01:39:58 +08:00
case OMPC_to:
[OpenMP] Parsing and sema support for the from clause Summary: The patch contains the parsing and sema support for the `from` clause. Patch based on the original post by Kelvin Li. Reviewers: hfinkel, carlo.bertolli, kkwli0, arpith-jacob, ABataev Subscribers: caomhin, cfe-commits Differential Revision: http://reviews.llvm.org/D18488 llvm-svn: 270882
2016-05-27 01:49:04 +08:00
case OMPC_from:
[OpenMP] Initial implementation of parse+sema for clause use_device_ptr of 'target data' http://reviews.llvm.org/D21904 This patch is similar to the implementation of 'private' clause: it adds a list of private pointers to be used within the target data region to store the device pointers returned by the runtime. Please refer to the following document for a full description of what the runtime witll return in this case (page 10 and 11): https://github.com/clang-omp/OffloadingDesign I am happy to answer any question related to the runtime interface to help reviewing this patch. llvm-svn: 275271
2016-07-13 23:37:16 +08:00
case OMPC_use_device_ptr:
[OPENMP50]Initial support for use_device_addr clause. Summary: Added parsing/sema analysis/serialization support for use_device_addr clauses. Reviewers: jdoerfert Subscribers: yaxunl, guansong, arphaman, sstefan1, llvm-commits, cfe-commits, caomhin Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D80404
2020-05-21 20:30:23 +08:00
case OMPC_use_device_addr:
[OpenMP] Initial implementation of parse+sema for OpenMP clause 'is_device_ptr' of target http://reviews.llvm.org/D22070 llvm-svn: 275282
2016-07-14 01:16:49 +08:00
case OMPC_is_device_ptr:
[OPENMP]Initial support for 'allocate' clause. Added parsing/sema analysis of the allocate clause. llvm-svn: 357068
2019-03-27 22:14:31 +08:00
case OMPC_allocate:
[OPENMP50]Add parsing/sema analysis for nontemporal clause. Add basic support for parsing/sema analysis of the nontemporal clause in simd-based directives.
2019-12-17 04:54:17 +08:00
case OMPC_nontemporal:
[OPENMP50]Initial support for inclusive clause. Added parsing/sema/serialization support for inclusive clause in scan directive.
2020-03-20 21:41:22 +08:00
case OMPC_inclusive:
[OPENMP50]Bassic support for exclusive clause. Added basic support (parsing/sema/serialization) for exclusive clause in scan directives.
2020-03-23 22:41:08 +08:00
case OMPC_exclusive:
[OPENMP50]Add initial support for 'affinity' clause. Summary: Added parsing/sema/serialization support for affinity clause in task directives. Reviewers: jdoerfert Subscribers: yaxunl, guansong, arphaman, llvm-commits, cfe-commits, caomhin Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D80148
2020-05-19 01:37:53 +08:00
case OMPC_affinity:
[OpenMP] Fix handling of clause on wrong directive, by Joel. E. Denny Summary: First, this patch fixes an assert failure when, for example, "omp for" has num_teams. Second, this patch prevents duplicate diagnostics when, for example, "omp for" has uniform. This patch makes the general assumption (even where it doesn't necessarily fix an existing bug) that it is worthless to perform sema for a clause that appears on a directive on which OpenMP does not permit that clause. However, due to this assumption, this patch suppresses some diagnostics that were expected in the test suite. I assert that those diagnostics were likely just distracting to the user. Reviewers: ABataev Reviewed By: ABataev Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D41841 llvm-svn: 322107
2018-01-10 03:21:04 +08:00
Clause = ParseOpenMPVarListClause(DKind, CKind, WrongDirective);
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
break;
[OpenMP] Implement '#pragma omp tile', by Michael Kruse (@Meinersbur). The tile directive is in OpenMP's Technical Report 8 and foreseeably will be part of the upcoming OpenMP 5.1 standard. This implementation is based on an AST transformation providing a de-sugared loop nest. This makes it simple to forward the de-sugared transformation to loop associated directives taking the tiled loops. In contrast to other loop associated directives, the OMPTileDirective does not use CapturedStmts. Letting loop associated directives consume loops from different capture context would be difficult. A significant amount of code generation logic is taking place in the Sema class. Eventually, I would prefer if these would move into the CodeGen component such that we could make use of the OpenMPIRBuilder, together with flang. Only expressions converting between the language's iteration variable and the logical iteration space need to take place in the semantic analyzer: Getting the of iterations (e.g. the overload resolution of `std::distance`) and converting the logical iteration number to the iteration variable (e.g. overload resolution of `iteration + .omp.iv`). In clang, only CXXForRangeStmt is also represented by its de-sugared components. However, OpenMP loop are not defined as syntatic sugar. Starting with an AST-based approach allows us to gradually move generated AST statements into CodeGen, instead all at once. I would also like to refactor `checkOpenMPLoop` into its functionalities in a follow-up. In this patch it is used twice. Once for checking proper nesting and emitting diagnostics, and additionally for deriving the logical iteration space per-loop (instead of for the loop nest). Differential Revision: https://reviews.llvm.org/D76342
2021-02-13 03:26:59 +08:00
case OMPC_sizes:
if (!FirstClause) {
Diag(Tok, diag::err_omp_more_one_clause)
<< getOpenMPDirectiveName(DKind) << getOpenMPClauseName(CKind) << 0;
ErrorFound = true;
}
Clause = ParseOpenMPSizesClause();
break;
[OPENMP50]Basic support for uses_allocators clause. Summary: Added parsing/sema/serialization supoprt for uses_allocators clause. Reviewers: jdoerfert Subscribers: yaxunl, guansong, arphaman, cfe-commits, caomhin Tags: #clang Differential Revision: https://reviews.llvm.org/D78577
2020-04-22 01:21:00 +08:00
case OMPC_uses_allocators:
Clause = ParseOpenMPUsesAllocatorClause(DKind);
break;
[OPENMP51]Support for the 'destroy' clause with interop variable. Added basic parsing/sema/serialization support to extend the existing 'destroy' clause for use with the 'interop' directive. Differential Revision: https://reviews.llvm.org/D98834
2021-03-18 07:43:47 +08:00
case OMPC_destroy:
if (DKind != OMPD_interop) {
if (!FirstClause) {
Diag(Tok, diag::err_omp_more_one_clause)
<< getOpenMPDirectiveName(DKind) << getOpenMPClauseName(CKind) << 0;
ErrorFound = true;
}
Clause = ParseOpenMPClause(CKind, WrongDirective);
break;
}
LLVM_FALLTHROUGH;
[OPENMP51]Initial support for the interop directive. Added basic parsing/sema/serialization support for interop directive. Support for the 'init' clause. Differential Revision: https://reviews.llvm.org/D98558
2021-03-16 04:09:46 +08:00
case OMPC_init:
[OPENMP51]Initial support for the use clause. Added basic parsing/sema/serialization support for the 'use' clause. Differential Revision: https://reviews.llvm.org/D98815
2021-03-18 04:04:08 +08:00
case OMPC_use:
[OPENMP51]Initial support for the interop directive. Added basic parsing/sema/serialization support for interop directive. Support for the 'init' clause. Differential Revision: https://reviews.llvm.org/D98558
2021-03-16 04:09:46 +08:00
Clause = ParseOpenMPInteropClause(CKind, WrongDirective);
break;
[OPENMP5.0]Add support for device_type clause in declare target construct. OpenMP 5.0 introduced new clause for declare target directive, device_type clause, which may accept values host, nohost, and any. Host means that the function must be emitted only for the host, nohost - only for the device, and any - for both, device and the host. llvm-svn: 369775
2019-08-24 00:11:14 +08:00
case OMPC_device_type:
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
case OMPC_unknown:
[OpenMP][NFC] Outline common functionality (skipUntilPragmaOpenMPEnd) The same code was repeated multiple times, we put it in a function now.
2020-02-22 03:48:56 +08:00
skipUntilPragmaOpenMPEnd(DKind);
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
break;
case OMPC_threadprivate:
[OPENMP 4.0] Support for 'uniform' clause in 'declare simd' directive. OpenMP 4.0 defines clause 'uniform' in 'declare simd' directive: 'uniform' '(' <argument-list> ')' The uniform clause declares one or more arguments to have an invariant value for all concurrent invocations of the function in the execution of a single SIMD loop. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266041
2016-04-12 13:28:34 +08:00
case OMPC_uniform:
[OPENMP]Use standard parsing for 'match' clause, NFC. Reused standard clauses parsing scheme for parsing/matching 'match' clause in 'declare variant' directive. llvm-svn: 372635
2019-09-24 02:13:31 +08:00
case OMPC_match:
[OpenMP] Fix handling of clause on wrong directive, by Joel. E. Denny Summary: First, this patch fixes an assert failure when, for example, "omp for" has num_teams. Second, this patch prevents duplicate diagnostics when, for example, "omp for" has uniform. This patch makes the general assumption (even where it doesn't necessarily fix an existing bug) that it is worthless to perform sema for a clause that appears on a directive on which OpenMP does not permit that clause. However, due to this assumption, this patch suppresses some diagnostics that were expected in the test suite. I assert that those diagnostics were likely just distracting to the user. Reviewers: ABataev Reviewed By: ABataev Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D41841 llvm-svn: 322107
2018-01-10 03:21:04 +08:00
if (!WrongDirective)
Diag(Tok, diag::err_omp_unexpected_clause)
<< getOpenMPClauseName(CKind) << getOpenMPDirectiveName(DKind);
Revert "[OPENMP] Fix for parsing OpenMP directives with extra braces, brackets and parens" These parser changes were redundant. The same or better recovery can be achieved with a one-line fix to SkipUntil() due to land in the next commit. This reverts commit r197553. llvm-svn: 197597
2013-12-19 03:10:49 +08:00
SkipUntil(tok::comma, tok::annot_pragma_openmp_end, StopBeforeMatch);
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
break;
[flang][openmp] Use common Directive and Clause enum from llvm/Frontend Summary: This patch is removing the custom enumeration for OpenMP Directives and Clauses and replace them with the newly tablegen generated one from llvm/Frontend. This is a first patch and some will follow to share the same infrastructure where possible. The next patch should use the clauses allowance defined in the tablegen file. Reviewers: jdoerfert, DavidTruby, sscalpone, kiranchandramohan, ichoyjx Reviewed By: DavidTruby, ichoyjx Subscribers: jholewinski, cfe-commits, dblaikie, MaskRay, ymandel, ichoyjx, mgorny, yaxunl, guansong, jfb, sstefan1, aaron.ballman, llvm-commits Tags: #llvm, #flang, #clang Differential Revision: https://reviews.llvm.org/D82906
2020-07-02 08:57:11 +08:00
default:
break;
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
}
[C++11] Use 'nullptr'. Parser edition. llvm-svn: 209275
2014-05-21 14:02:52 +08:00
return ErrorFound ? nullptr : Clause;
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
}
[OPENMP 4.0] Parsing/sema analysis for 'simdlen' clause in 'declare simd' construct. OpenMP 4.0 defines '#pragma omp declare simd' construct that may have associated 'simdlen' clause with constant positive expression as an argument: simdlen(<const_expr>) Patch adds parsin and semantic analysis for simdlen clause. llvm-svn: 265668
2016-04-07 20:45:37 +08:00
/// Parses simple expression in parens for single-expression clauses of OpenMP
/// constructs.
/// \param RLoc Returned location of right paren.
ExprResult Parser::ParseOpenMPParensExpr(StringRef ClauseName,
[OPENMP5.0]Add basic support for declare variant directive. Added basic support for declare variant directive and its match clause with user context selector. llvm-svn: 371892
2019-09-14 04:18:17 +08:00
SourceLocation &RLoc,
bool IsAddressOfOperand) {
[OPENMP 4.0] Parsing/sema analysis for 'simdlen' clause in 'declare simd' construct. OpenMP 4.0 defines '#pragma omp declare simd' construct that may have associated 'simdlen' clause with constant positive expression as an argument: simdlen(<const_expr>) Patch adds parsin and semantic analysis for simdlen clause. llvm-svn: 265668
2016-04-07 20:45:37 +08:00
BalancedDelimiterTracker T(*this, tok::l_paren, tok::annot_pragma_openmp_end);
if (T.expectAndConsume(diag::err_expected_lparen_after, ClauseName.data()))
return ExprError();
SourceLocation ELoc = Tok.getLocation();
[OpenMP][NFC] Clang format ParseOpenMP ParseOpenMP.cpp was pretty much clang-formatted except a few minor locations. Let's make it a clang formatted file. Reviewed By: JonChesterfield Differential Revision: https://reviews.llvm.org/D90440
2020-10-30 07:44:28 +08:00
ExprResult LHS(
ParseCastExpression(AnyCastExpr, IsAddressOfOperand, NotTypeCast));
[OPENMP 4.0] Parsing/sema analysis for 'simdlen' clause in 'declare simd' construct. OpenMP 4.0 defines '#pragma omp declare simd' construct that may have associated 'simdlen' clause with constant positive expression as an argument: simdlen(<const_expr>) Patch adds parsin and semantic analysis for simdlen clause. llvm-svn: 265668
2016-04-07 20:45:37 +08:00
ExprResult Val(ParseRHSOfBinaryExpression(LHS, prec::Conditional));
Refactor the way we handle diagnosing unused expression results. Rather than sprinkle calls to DiagnoseUnusedExprResult() around in places where we want diagnostics, we now diagnose unused expression statements and full expressions in a more generic way when acting on the final expression statement. This results in more appropriate diagnostics for [[nodiscard]] where we were previously lacking them, such as when the body of a for loop is not a compound statement. This patch fixes PR39837. llvm-svn: 350404
2019-01-05 00:58:14 +08:00
Val = Actions.ActOnFinishFullExpr(Val.get(), ELoc, /*DiscardedValue*/ false);
[OPENMP 4.0] Parsing/sema analysis for 'simdlen' clause in 'declare simd' construct. OpenMP 4.0 defines '#pragma omp declare simd' construct that may have associated 'simdlen' clause with constant positive expression as an argument: simdlen(<const_expr>) Patch adds parsin and semantic analysis for simdlen clause. llvm-svn: 265668
2016-04-07 20:45:37 +08:00
// Parse ')'.
[OPENMP] Make clauses closing loc point to right bracket. For some of the clauses the closing location erroneously points to the beginning of the next clause rather than on the location of the closing bracket of the clause. llvm-svn: 336460
2018-07-07 03:35:42 +08:00
RLoc = Tok.getLocation();
if (!T.consumeClose())
RLoc = T.getCloseLocation();
[OPENMP 4.0] Parsing/sema analysis for 'simdlen' clause in 'declare simd' construct. OpenMP 4.0 defines '#pragma omp declare simd' construct that may have associated 'simdlen' clause with constant positive expression as an argument: simdlen(<const_expr>) Patch adds parsin and semantic analysis for simdlen clause. llvm-svn: 265668
2016-04-07 20:45:37 +08:00
return Val;
}
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Parsing of OpenMP clauses with single expressions like 'final',
[OPENMP 4.5] Parsing/sema analysis for 'priority' clause. OpenMP 4.5 defines new clause 'priority' for 'task', 'taskloop' and 'taskloop simd' directives. Added parsing and sema analysis for 'priority' clause in 'task' and 'taskloop' directives. llvm-svn: 254398
2015-12-01 18:17:31 +08:00
/// 'collapse', 'safelen', 'num_threads', 'simdlen', 'num_teams',
[OPENMP50]Initial support for detach clause in task directive. Added parsing/sema/serialization support for detach clause.
2020-03-17 21:17:42 +08:00
/// 'thread_limit', 'simdlen', 'priority', 'grainsize', 'num_tasks', 'hint' or
/// 'detach'.
[OPENMP] 'if' clause support (no CodeGen support) llvm-svn: 201297
2014-02-13 13:29:23 +08:00
///
[OPENMP] Initial parsing and sema analysis for 'final' clause. llvm-svn: 213232
2014-07-17 15:32:53 +08:00
/// final-clause:
/// 'final' '(' expression ')'
///
[OPENMP] parsing of clause 'safelen' (for directive 'omp simd') llvm-svn: 204428
2014-03-21 12:51:18 +08:00
/// num_threads-clause:
/// 'num_threads' '(' expression ')'
///
/// safelen-clause:
/// 'safelen' '(' expression ')'
///
[OPENMP 4.1] Initial support for 'simdlen' clause. Add parsing/sema analysis for 'simdlen' clause in simd directives. Also add check that if both 'safelen' and 'simdlen' clauses are specified, the value of 'simdlen' parameter is less than the value of 'safelen' parameter. llvm-svn: 245692
2015-08-21 19:14:16 +08:00
/// simdlen-clause:
/// 'simdlen' '(' expression ')'
///
Parsing/Sema for OMPCollapseClause. Actual usage in Sema for collapsing loops will in some future patch. llvm-svn: 209660
2014-05-27 23:12:19 +08:00
/// collapse-clause:
/// 'collapse' '(' expression ')'
///
[OPENMP 4.5] Parsing/sema analysis for 'priority' clause. OpenMP 4.5 defines new clause 'priority' for 'task', 'taskloop' and 'taskloop simd' directives. Added parsing and sema analysis for 'priority' clause in 'task' and 'taskloop' directives. llvm-svn: 254398
2015-12-01 18:17:31 +08:00
/// priority-clause:
/// 'priority' '(' expression ')'
///
[OPENMP 4.5] parsing/sema support for 'grainsize' clause. OpenMP 4.5 adds 'taksloop' and 'taskloop simd' directives, which have 'grainsize' clause. Patch adds parsing/sema analysis of this clause. llvm-svn: 254903
2015-12-07 20:52:51 +08:00
/// grainsize-clause:
/// 'grainsize' '(' expression ')'
///
[OPENMP 4.5] Parsing/sema for 'num_tasks' clause. OpenMP 4.5 adds directives 'taskloop' and 'taskloop simd'. These directives support clause 'num_tasks'. Patch adds parsing/semantic analysis for this clause. llvm-svn: 255008
2015-12-08 20:06:20 +08:00
/// num_tasks-clause:
/// 'num_tasks' '(' expression ')'
///
[OPENMP 4.5] Parsing/sema for 'hint' clause of 'critical' directive. OpenMP 4.5 adds 'hint' clause to critical directive. Patch adds parsing/semantic analysis for this clause. llvm-svn: 255625
2015-12-15 16:19:24 +08:00
/// hint-clause:
/// 'hint' '(' expression ')'
///
[OPENMP 5.0]Initial support for 'allocator' clause. Added parsing/sema analysis/serialization/deserialization for the 'allocator' clause of the 'allocate' directive. llvm-svn: 355952
2019-03-13 02:52:33 +08:00
/// allocator-clause:
/// 'allocator' '(' expression ')'
///
[OPENMP50]Initial support for detach clause in task directive. Added parsing/sema/serialization support for detach clause.
2020-03-17 21:17:42 +08:00
/// detach-clause:
/// 'detach' '(' event-handler-expression ')'
///
[OpenMP] Fix handling of clause on wrong directive, by Joel. E. Denny Summary: First, this patch fixes an assert failure when, for example, "omp for" has num_teams. Second, this patch prevents duplicate diagnostics when, for example, "omp for" has uniform. This patch makes the general assumption (even where it doesn't necessarily fix an existing bug) that it is worthless to perform sema for a clause that appears on a directive on which OpenMP does not permit that clause. However, due to this assumption, this patch suppresses some diagnostics that were expected in the test suite. I assert that those diagnostics were likely just distracting to the user. Reviewers: ABataev Reviewed By: ABataev Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D41841 llvm-svn: 322107
2018-01-10 03:21:04 +08:00
OMPClause *Parser::ParseOpenMPSingleExprClause(OpenMPClauseKind Kind,
bool ParseOnly) {
[OPENMP] 'if' clause support (no CodeGen support) llvm-svn: 201297
2014-02-13 13:29:23 +08:00
SourceLocation Loc = ConsumeToken();
[OPENMP 4.0] Parsing/sema analysis for 'simdlen' clause in 'declare simd' construct. OpenMP 4.0 defines '#pragma omp declare simd' construct that may have associated 'simdlen' clause with constant positive expression as an argument: simdlen(<const_expr>) Patch adds parsin and semantic analysis for simdlen clause. llvm-svn: 265668
2016-04-07 20:45:37 +08:00
SourceLocation LLoc = Tok.getLocation();
SourceLocation RLoc;
[OPENMP] 'if' clause support (no CodeGen support) llvm-svn: 201297
2014-02-13 13:29:23 +08:00
[OPENMP 4.0] Parsing/sema analysis for 'simdlen' clause in 'declare simd' construct. OpenMP 4.0 defines '#pragma omp declare simd' construct that may have associated 'simdlen' clause with constant positive expression as an argument: simdlen(<const_expr>) Patch adds parsin and semantic analysis for simdlen clause. llvm-svn: 265668
2016-04-07 20:45:37 +08:00
ExprResult Val = ParseOpenMPParensExpr(getOpenMPClauseName(Kind), RLoc);
[OPENMP] 'if' clause support (no CodeGen support) llvm-svn: 201297
2014-02-13 13:29:23 +08:00
if (Val.isInvalid())
[C++11] Use 'nullptr'. Parser edition. llvm-svn: 209275
2014-05-21 14:02:52 +08:00
return nullptr;
[OPENMP] 'if' clause support (no CodeGen support) llvm-svn: 201297
2014-02-13 13:29:23 +08:00
[OpenMP] Fix handling of clause on wrong directive, by Joel. E. Denny Summary: First, this patch fixes an assert failure when, for example, "omp for" has num_teams. Second, this patch prevents duplicate diagnostics when, for example, "omp for" has uniform. This patch makes the general assumption (even where it doesn't necessarily fix an existing bug) that it is worthless to perform sema for a clause that appears on a directive on which OpenMP does not permit that clause. However, due to this assumption, this patch suppresses some diagnostics that were expected in the test suite. I assert that those diagnostics were likely just distracting to the user. Reviewers: ABataev Reviewed By: ABataev Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D41841 llvm-svn: 322107
2018-01-10 03:21:04 +08:00
if (ParseOnly)
return nullptr;
[OPENMP 4.0] Parsing/sema analysis for 'simdlen' clause in 'declare simd' construct. OpenMP 4.0 defines '#pragma omp declare simd' construct that may have associated 'simdlen' clause with constant positive expression as an argument: simdlen(<const_expr>) Patch adds parsin and semantic analysis for simdlen clause. llvm-svn: 265668
2016-04-07 20:45:37 +08:00
return Actions.ActOnOpenMPSingleExprClause(Kind, Val.get(), Loc, LLoc, RLoc);
[OPENMP] 'if' clause support (no CodeGen support) llvm-svn: 201297
2014-02-13 13:29:23 +08:00
}
[OPENMP51]Initial support for the interop directive. Added basic parsing/sema/serialization support for interop directive. Support for the 'init' clause. Differential Revision: https://reviews.llvm.org/D98558
2021-03-16 04:09:46 +08:00
/// Parsing of OpenMP clauses that use an interop-var.
///
/// init-clause:
/// init([interop-modifier, ]interop-type[[, interop-type] ... ]:interop-var)
///
/// destroy-clause:
/// destroy(interop-var)
///
/// use-clause:
/// use(interop-var)
///
/// interop-modifier:
/// prefer_type(preference-list)
///
/// preference-list:
/// foreign-runtime-id [, foreign-runtime-id]...
///
/// foreign-runtime-id:
/// <string-literal> | <constant-integral-expression>
///
/// interop-type:
/// target | targetsync
///
OMPClause *Parser::ParseOpenMPInteropClause(OpenMPClauseKind Kind,
bool ParseOnly) {
SourceLocation Loc = ConsumeToken();
// Parse '('.
BalancedDelimiterTracker T(*this, tok::l_paren, tok::annot_pragma_openmp_end);
if (T.expectAndConsume(diag::err_expected_lparen_after,
getOpenMPClauseName(Kind).data()))
return nullptr;
bool IsTarget = false;
bool IsTargetSync = false;
SmallVector<Expr *, 4> Prefs;
if (Kind == OMPC_init) {
// Parse optional interop-modifier.
if (Tok.is(tok::identifier) && PP.getSpelling(Tok) == "prefer_type") {
ConsumeToken();
BalancedDelimiterTracker PT(*this, tok::l_paren,
tok::annot_pragma_openmp_end);
if (PT.expectAndConsume(diag::err_expected_lparen_after, "prefer_type"))
return nullptr;
while (Tok.isNot(tok::r_paren)) {
SourceLocation Loc = Tok.getLocation();
ExprResult LHS = ParseCastExpression(AnyCastExpr);
ExprResult PTExpr = Actions.CorrectDelayedTyposInExpr(
ParseRHSOfBinaryExpression(LHS, prec::Conditional));
PTExpr = Actions.ActOnFinishFullExpr(PTExpr.get(), Loc,
/*DiscardedValue=*/false);
if (PTExpr.isUsable())
Prefs.push_back(PTExpr.get());
else
SkipUntil(tok::comma, tok::r_paren, tok::annot_pragma_openmp_end,
StopBeforeMatch);
if (Tok.is(tok::comma))
ConsumeToken();
}
PT.consumeClose();
}
if (!Prefs.empty()) {
if (Tok.is(tok::comma))
ConsumeToken();
else
Diag(Tok, diag::err_omp_expected_punc_after_interop_mod);
}
// Parse the interop-types.
[OPENMP51]Initial parsing/sema for append_args clause for 'declare variant' Adds initial parsing and sema for the 'append_args' clause. Note that an AST clause is not created as it instead adds its values to the OMPDeclareVariantAttr. Differential Revision: https://reviews.llvm.org/D111854
2021-10-15 05:28:51 +08:00
if (Optional<OMPDeclareVariantAttr::InteropType> IType =
parseInteropTypeList(*this)) {
IsTarget = IType != OMPDeclareVariantAttr::TargetSync;
IsTargetSync = IType != OMPDeclareVariantAttr::Target;
if (Tok.isNot(tok::colon))
Diag(Tok, diag::warn_pragma_expected_colon) << "interop types";
[OPENMP51]Initial support for the interop directive. Added basic parsing/sema/serialization support for interop directive. Support for the 'init' clause. Differential Revision: https://reviews.llvm.org/D98558
2021-03-16 04:09:46 +08:00
}
if (Tok.is(tok::colon))
ConsumeToken();
}
// Parse the variable.
SourceLocation VarLoc = Tok.getLocation();
ExprResult InteropVarExpr =
Actions.CorrectDelayedTyposInExpr(ParseAssignmentExpression());
if (!InteropVarExpr.isUsable()) {
SkipUntil(tok::comma, tok::r_paren, tok::annot_pragma_openmp_end,
StopBeforeMatch);
}
// Parse ')'.
SourceLocation RLoc = Tok.getLocation();
if (!T.consumeClose())
RLoc = T.getCloseLocation();
if (ParseOnly || !InteropVarExpr.isUsable() ||
(Kind == OMPC_init && !IsTarget && !IsTargetSync))
return nullptr;
if (Kind == OMPC_init)
return Actions.ActOnOpenMPInitClause(InteropVarExpr.get(), Prefs, IsTarget,
IsTargetSync, Loc, T.getOpenLocation(),
VarLoc, RLoc);
[OPENMP51]Initial support for the use clause. Added basic parsing/sema/serialization support for the 'use' clause. Differential Revision: https://reviews.llvm.org/D98815
2021-03-18 04:04:08 +08:00
if (Kind == OMPC_use)
return Actions.ActOnOpenMPUseClause(InteropVarExpr.get(), Loc,
T.getOpenLocation(), VarLoc, RLoc);
[OPENMP51]Initial support for the interop directive. Added basic parsing/sema/serialization support for interop directive. Support for the 'init' clause. Differential Revision: https://reviews.llvm.org/D98558
2021-03-16 04:09:46 +08:00
[OPENMP51]Support for the 'destroy' clause with interop variable. Added basic parsing/sema/serialization support to extend the existing 'destroy' clause for use with the 'interop' directive. Differential Revision: https://reviews.llvm.org/D98834
2021-03-18 07:43:47 +08:00
if (Kind == OMPC_destroy)
return Actions.ActOnOpenMPDestroyClause(InteropVarExpr.get(), Loc,
T.getOpenLocation(), VarLoc, RLoc);
[OPENMP51]Initial support for the interop directive. Added basic parsing/sema/serialization support for interop directive. Support for the 'init' clause. Differential Revision: https://reviews.llvm.org/D98558
2021-03-16 04:09:46 +08:00
llvm_unreachable("Unexpected interop variable clause.");
}
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Parsing of simple OpenMP clauses like 'default' or 'proc_bind'.
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
///
/// default-clause:
[OpenMP] Add firstprivate as a default data-sharing attribute to clang This implements the default(firstprivate) clause as defined in OpenMP Technical Report 8 (2.22.4). Reviewed By: jdoerfert, ABataev Differential Revision: https://reviews.llvm.org/D75591
2020-07-13 11:19:40 +08:00
/// 'default' '(' 'none' | 'shared' | 'firstprivate' ')'
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
///
[OPENMP] 'proc_bind' clause support - Parsing and sema analysis for OpenMP clause 'proc_bind' llvm-svn: 208060
2014-05-06 14:04:14 +08:00
/// proc_bind-clause:
[OPENMP50]Support 'update' clause for 'depobj' directive. Added basic support (parsing/sema/serialization) for 'update' clause in 'depobj' directive.
2020-03-04 02:22:35 +08:00
/// 'proc_bind' '(' 'master' | 'close' | 'spread' ')'
///
/// update-clause:
/// 'update' '(' 'in' | 'out' | 'inout' | 'mutexinoutset' ')'
[OPENMP] 'proc_bind' clause support - Parsing and sema analysis for OpenMP clause 'proc_bind' llvm-svn: 208060
2014-05-06 14:04:14 +08:00
///
[OpenMP] Fix handling of clause on wrong directive, by Joel. E. Denny Summary: First, this patch fixes an assert failure when, for example, "omp for" has num_teams. Second, this patch prevents duplicate diagnostics when, for example, "omp for" has uniform. This patch makes the general assumption (even where it doesn't necessarily fix an existing bug) that it is worthless to perform sema for a clause that appears on a directive on which OpenMP does not permit that clause. However, due to this assumption, this patch suppresses some diagnostics that were expected in the test suite. I assert that those diagnostics were likely just distracting to the user. Reviewers: ABataev Reviewed By: ABataev Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D41841 llvm-svn: 322107
2018-01-10 03:21:04 +08:00
OMPClause *Parser::ParseOpenMPSimpleClause(OpenMPClauseKind Kind,
bool ParseOnly) {
[OPENMP5.0]Add support for device_type clause in declare target construct. OpenMP 5.0 introduced new clause for declare target directive, device_type clause, which may accept values host, nohost, and any. Host means that the function must be emitted only for the host, nohost - only for the device, and any - for both, device and the host. llvm-svn: 369775
2019-08-24 00:11:14 +08:00
llvm::Optional<SimpleClauseData> Val = parseOpenMPSimpleClause(*this, Kind);
if (!Val || ParseOnly)
[OpenMP] Fix handling of clause on wrong directive, by Joel. E. Denny Summary: First, this patch fixes an assert failure when, for example, "omp for" has num_teams. Second, this patch prevents duplicate diagnostics when, for example, "omp for" has uniform. This patch makes the general assumption (even where it doesn't necessarily fix an existing bug) that it is worthless to perform sema for a clause that appears on a directive on which OpenMP does not permit that clause. However, due to this assumption, this patch suppresses some diagnostics that were expected in the test suite. I assert that those diagnostics were likely just distracting to the user. Reviewers: ABataev Reviewed By: ABataev Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D41841 llvm-svn: 322107
2018-01-10 03:21:04 +08:00
return nullptr;
[OpenMP] Add firstprivate as a default data-sharing attribute to clang This implements the default(firstprivate) clause as defined in OpenMP Technical Report 8 (2.22.4). Reviewed By: jdoerfert, ABataev Differential Revision: https://reviews.llvm.org/D75591
2020-07-13 11:19:40 +08:00
if (getLangOpts().OpenMP < 51 && Kind == OMPC_default &&
static_cast<DefaultKind>(Val.getValue().Type) ==
OMP_DEFAULT_firstprivate) {
Diag(Val.getValue().LOpen, diag::err_omp_invalid_dsa)
<< getOpenMPClauseName(OMPC_firstprivate)
<< getOpenMPClauseName(OMPC_default) << "5.1";
return nullptr;
}
[OPENMP5.0]Add support for device_type clause in declare target construct. OpenMP 5.0 introduced new clause for declare target directive, device_type clause, which may accept values host, nohost, and any. Host means that the function must be emitted only for the host, nohost - only for the device, and any - for both, device and the host. llvm-svn: 369775
2019-08-24 00:11:14 +08:00
return Actions.ActOnOpenMPSimpleClause(
Kind, Val.getValue().Type, Val.getValue().TypeLoc, Val.getValue().LOpen,
Val.getValue().Loc, Val.getValue().RLoc);
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
}
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Parsing of OpenMP clauses like 'ordered'.
[OPENMP] Initial support for 'ordered' clause. llvm-svn: 211347
2014-06-20 17:44:06 +08:00
///
/// ordered-clause:
/// 'ordered'
///
[OPENMP] Initial support for 'nowait' clause. llvm-svn: 211352
2014-06-20 19:19:47 +08:00
/// nowait-clause:
/// 'nowait'
///
[OPENMP] Initial support for parsing and sema analysis of 'untied' clause. llvm-svn: 213257
2014-07-17 20:19:31 +08:00
/// untied-clause:
/// 'untied'
///
[OPENMP] Initial parsing and sema analysis of 'mergeable' clause. llvm-svn: 213262
2014-07-17 20:47:03 +08:00
/// mergeable-clause:
/// 'mergeable'
///
[OPENMP] Initial parsing and sema analysis for 'read' clause in 'atomic' directive. llvm-svn: 213717
2014-07-23 10:27:21 +08:00
/// read-clause:
/// 'read'
///
[OPENMP 4.1] Add 'threads' clause for '#pragma omp ordered'. OpenMP 4.1 extends format of '#pragma omp ordered'. It adds 3 additional clauses: 'threads', 'simd' and 'depend'. If no clause is specified, the ordered construct behaves as if the threads clause had been specified. If the threads clause is specified, the threads in the team executing the loop region execute ordered regions sequentially in the order of the loop iterations. The loop region to which an ordered region without any clause or with a threads clause binds must have an ordered clause without the parameter specified on the corresponding loop directive. llvm-svn: 248569
2015-09-25 18:37:12 +08:00
/// threads-clause:
/// 'threads'
///
[OPENMP 4.1] Add 'simd' clause for 'ordered' directive. Parsing and sema analysis for 'simd' clause in 'ordered' directive. Description If the simd clause is specified, the ordered regions encountered by any thread will use only a single SIMD lane to execute the ordered regions in the order of the loop iterations. Restrictions An ordered construct with the simd clause is the only OpenMP construct that can appear in the simd region llvm-svn: 248696
2015-09-28 14:39:35 +08:00
/// simd-clause:
/// 'simd'
///
[OPENMP 4.5] parsing/sema support for 'nogroup' clause. OpenMP 4.5 adds 'taskloop' and 'taskloop simd' directives. These directives have new 'nogroup' clause. Patch adds basic parsing/sema support for this clause. llvm-svn: 254899
2015-12-07 18:51:44 +08:00
/// nogroup-clause:
/// 'nogroup'
///
[OpenMP] Fix handling of clause on wrong directive, by Joel. E. Denny Summary: First, this patch fixes an assert failure when, for example, "omp for" has num_teams. Second, this patch prevents duplicate diagnostics when, for example, "omp for" has uniform. This patch makes the general assumption (even where it doesn't necessarily fix an existing bug) that it is worthless to perform sema for a clause that appears on a directive on which OpenMP does not permit that clause. However, due to this assumption, this patch suppresses some diagnostics that were expected in the test suite. I assert that those diagnostics were likely just distracting to the user. Reviewers: ABataev Reviewed By: ABataev Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D41841 llvm-svn: 322107
2018-01-10 03:21:04 +08:00
OMPClause *Parser::ParseOpenMPClause(OpenMPClauseKind Kind, bool ParseOnly) {
[OPENMP] Initial support for 'ordered' clause. llvm-svn: 211347
2014-06-20 17:44:06 +08:00
SourceLocation Loc = Tok.getLocation();
ConsumeAnyToken();
[OpenMP] Fix handling of clause on wrong directive, by Joel. E. Denny Summary: First, this patch fixes an assert failure when, for example, "omp for" has num_teams. Second, this patch prevents duplicate diagnostics when, for example, "omp for" has uniform. This patch makes the general assumption (even where it doesn't necessarily fix an existing bug) that it is worthless to perform sema for a clause that appears on a directive on which OpenMP does not permit that clause. However, due to this assumption, this patch suppresses some diagnostics that were expected in the test suite. I assert that those diagnostics were likely just distracting to the user. Reviewers: ABataev Reviewed By: ABataev Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D41841 llvm-svn: 322107
2018-01-10 03:21:04 +08:00
if (ParseOnly)
return nullptr;
[OPENMP] Initial support for 'ordered' clause. llvm-svn: 211347
2014-06-20 17:44:06 +08:00
return Actions.ActOnOpenMPClause(Kind, Loc, Tok.getLocation());
}
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Parsing of OpenMP clauses with single expressions and some additional
[OPENMP] Initial support for 'schedule' clause. llvm-svn: 211342
2014-06-20 15:16:17 +08:00
/// argument like 'schedule' or 'dist_schedule'.
///
/// schedule-clause:
[OPENMP 4.5] Sema/parsing support for extended format of 'schedule' clause. OpenMP 4.0-3.1 supports the next format of ‘schedule’ clause: schedule(kind[, chunk_size]) Where kind can be one of ‘static’, ‘dynamic’, ‘guided’, ‘auto’ or ‘runtime’. OpenMP 4.5 defines the format: schedule([modifier [, modifier]:]kind[, chunk_size]) Modifier can be one of ‘monotonic’, ‘nonmonotonic’ or ‘simd’. llvm-svn: 256487
2015-12-28 15:25:51 +08:00
/// 'schedule' '(' [ modifier [ ',' modifier ] ':' ] kind [',' expression ]
/// ')'
[OPENMP] Initial support for 'schedule' clause. llvm-svn: 211342
2014-06-20 15:16:17 +08:00
///
[OPENMP 4.1] Parsing/sema analysis for extended format of 'if' clause. OpenMP 4.1 added special 'directive-name-modifier' to the 'if' clause. Format of 'if' clause is as follows: ``` if([ directive-name-modifier :] scalar-logical-expression) ``` The restriction rules are also changed. 1. If any 'if' clause on the directive includes a 'directive-name-modifier' then all 'if' clauses on the directive must include a 'directive-name-modifier'. 2. At most one 'if' clause without a 'directive-name-modifier' can appear on the directive. 3. At most one 'if' clause with some particular 'directive-name-modifier' can appear on the directive. 'directive-name-modifier' is important for combined directives and allows to separate conditions in 'if' clause for simple sub-directives in combined directive. This 'directive-name-modifier' identifies the sub-directive to which this 'if' clause must be applied. llvm-svn: 246747
2015-09-03 15:23:48 +08:00
/// if-clause:
/// 'if' '(' [ directive-name-modifier ':' ] expression ')'
///
[OpenMP] Parsing + sema for defaultmap clause. Summary: This patch adds parsing + sema for the defaultmap clause associated with the target directive (among others). Reviewers: ABataev Differential Revision: http://reviews.llvm.org/D16527 llvm-svn: 258817
2016-01-27 00:37:23 +08:00
/// defaultmap:
[OPENMP50] Fix PR45469: Consider variable-category of defaultmap clause as optional. Summary: According to the standard, variable-category is the optional part of the defaultmap clause while the compiler always requires it. Turned it into optional part. Reviewers: jdoerfert Subscribers: yaxunl, guansong, cfe-commits, caomhin Tags: #clang Differential Revision: https://reviews.llvm.org/D77751
2020-04-09 03:19:54 +08:00
/// 'defaultmap' '(' modifier [ ':' kind ] ')'
[OpenMP] Parsing + sema for defaultmap clause. Summary: This patch adds parsing + sema for the defaultmap clause associated with the target directive (among others). Reviewers: ABataev Differential Revision: http://reviews.llvm.org/D16527 llvm-svn: 258817
2016-01-27 00:37:23 +08:00
///
[OPENMP50]Add support for extended device clause in target directives. Added parsing/sema/serialization support for extended device clause in executable target directives.
2020-03-19 03:01:15 +08:00
/// device-clause:
/// 'device' '(' [ device-modifier ':' ] expression ')'
///
OMPClause *Parser::ParseOpenMPSingleExprWithArgClause(OpenMPDirectiveKind DKind,
OpenMPClauseKind Kind,
[OpenMP] Fix handling of clause on wrong directive, by Joel. E. Denny Summary: First, this patch fixes an assert failure when, for example, "omp for" has num_teams. Second, this patch prevents duplicate diagnostics when, for example, "omp for" has uniform. This patch makes the general assumption (even where it doesn't necessarily fix an existing bug) that it is worthless to perform sema for a clause that appears on a directive on which OpenMP does not permit that clause. However, due to this assumption, this patch suppresses some diagnostics that were expected in the test suite. I assert that those diagnostics were likely just distracting to the user. Reviewers: ABataev Reviewed By: ABataev Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D41841 llvm-svn: 322107
2018-01-10 03:21:04 +08:00
bool ParseOnly) {
[OPENMP] Initial support for 'schedule' clause. llvm-svn: 211342
2014-06-20 15:16:17 +08:00
SourceLocation Loc = ConsumeToken();
[OPENMP 4.1] Parsing/sema analysis for extended format of 'if' clause. OpenMP 4.1 added special 'directive-name-modifier' to the 'if' clause. Format of 'if' clause is as follows: ``` if([ directive-name-modifier :] scalar-logical-expression) ``` The restriction rules are also changed. 1. If any 'if' clause on the directive includes a 'directive-name-modifier' then all 'if' clauses on the directive must include a 'directive-name-modifier'. 2. At most one 'if' clause without a 'directive-name-modifier' can appear on the directive. 3. At most one 'if' clause with some particular 'directive-name-modifier' can appear on the directive. 'directive-name-modifier' is important for combined directives and allows to separate conditions in 'if' clause for simple sub-directives in combined directive. This 'directive-name-modifier' identifies the sub-directive to which this 'if' clause must be applied. llvm-svn: 246747
2015-09-03 15:23:48 +08:00
SourceLocation DelimLoc;
[OPENMP] Initial support for 'schedule' clause. llvm-svn: 211342
2014-06-20 15:16:17 +08:00
// Parse '('.
BalancedDelimiterTracker T(*this, tok::l_paren, tok::annot_pragma_openmp_end);
if (T.expectAndConsume(diag::err_expected_lparen_after,
[OpenMP][NFCI] Move OpenMP clause information to `lib/Frontend/OpenMP` This is a cleanup and normalization patch that also enables reuse with Flang later on. A follow up will clean up and move the directive -> clauses mapping. Reviewed By: fghanim Differential Revision: https://reviews.llvm.org/D77112
2020-03-31 08:58:40 +08:00
getOpenMPClauseName(Kind).data()))
[OPENMP] Initial support for 'schedule' clause. llvm-svn: 211342
2014-06-20 15:16:17 +08:00
return nullptr;
ExprResult Val;
[OPENMP 4.5] Sema/parsing support for extended format of 'schedule' clause. OpenMP 4.0-3.1 supports the next format of ‘schedule’ clause: schedule(kind[, chunk_size]) Where kind can be one of ‘static’, ‘dynamic’, ‘guided’, ‘auto’ or ‘runtime’. OpenMP 4.5 defines the format: schedule([modifier [, modifier]:]kind[, chunk_size]) Modifier can be one of ‘monotonic’, ‘nonmonotonic’ or ‘simd’. llvm-svn: 256487
2015-12-28 15:25:51 +08:00
SmallVector<unsigned, 4> Arg;
SmallVector<SourceLocation, 4> KLoc;
[OPENMP 4.1] Parsing/sema analysis for extended format of 'if' clause. OpenMP 4.1 added special 'directive-name-modifier' to the 'if' clause. Format of 'if' clause is as follows: ``` if([ directive-name-modifier :] scalar-logical-expression) ``` The restriction rules are also changed. 1. If any 'if' clause on the directive includes a 'directive-name-modifier' then all 'if' clauses on the directive must include a 'directive-name-modifier'. 2. At most one 'if' clause without a 'directive-name-modifier' can appear on the directive. 3. At most one 'if' clause with some particular 'directive-name-modifier' can appear on the directive. 'directive-name-modifier' is important for combined directives and allows to separate conditions in 'if' clause for simple sub-directives in combined directive. This 'directive-name-modifier' identifies the sub-directive to which this 'if' clause must be applied. llvm-svn: 246747
2015-09-03 15:23:48 +08:00
if (Kind == OMPC_schedule) {
[OPENMP 4.5] Sema/parsing support for extended format of 'schedule' clause. OpenMP 4.0-3.1 supports the next format of ‘schedule’ clause: schedule(kind[, chunk_size]) Where kind can be one of ‘static’, ‘dynamic’, ‘guided’, ‘auto’ or ‘runtime’. OpenMP 4.5 defines the format: schedule([modifier [, modifier]:]kind[, chunk_size]) Modifier can be one of ‘monotonic’, ‘nonmonotonic’ or ‘simd’. llvm-svn: 256487
2015-12-28 15:25:51 +08:00
enum { Modifier1, Modifier2, ScheduleKind, NumberOfElements };
Arg.resize(NumberOfElements);
KLoc.resize(NumberOfElements);
Arg[Modifier1] = OMPC_SCHEDULE_MODIFIER_unknown;
Arg[Modifier2] = OMPC_SCHEDULE_MODIFIER_unknown;
Arg[ScheduleKind] = OMPC_SCHEDULE_unknown;
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-24 03:53:05 +08:00
unsigned KindModifier = getOpenMPSimpleClauseType(
[OpenMP][OpenACC] Implement `ompx_hold` map type modifier extension in Clang (1/2) This patch implements Clang support for an original OpenMP extension we have developed to support OpenACC: the `ompx_hold` map type modifier. The next patch in this series, D106510, implements OpenMP runtime support. Consider the following example: ``` #pragma omp target data map(ompx_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 `ompx_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. (As usual, the standard OpenMP reference count for `x` must also reach zero before the data is unmapped.) Justification for inclusion in Clang and LLVM's OpenMP runtime: * The `ompx_hold` modifier supports OpenACC functionality (structured reference count) that cannot be achieved in standard OpenMP, as of 5.1. * The runtime implementation for `ompx_hold` (next patch) will thus be used by Flang's OpenACC support. * The Clang implementation for `ompx_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 `ompx_hold` is also used by the tests in the runtime implementation. That syntactic support makes the tests more readable than low-level runtime calls can. Moreover, upstream Flang and Clang do not yet support OpenACC syntax sufficiently for writing the tests. * More generally, the Clang implementation enables a clean separation of concerns between OpenACC and OpenMP development in LLVM. That is, LLVM's OpenMP developers can discuss, modify, and debug LLVM's extended OpenMP implementation and test suite without directly considering OpenACC's language and execution model, which can be handled by LLVM's OpenACC developers. * OpenMP users might find the `ompx_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. For example, it explains how the runtime must support two reference counts, as specified by OpenACC. Clang recognizes `ompx_hold` unless `-fno-openmp-extensions`, a new command-line option introduced by this patch, is specified. Reviewed By: ABataev, jdoerfert, protze.joachim, grokos Differential Revision: https://reviews.llvm.org/D106509
2021-09-01 03:17:07 +08:00
Kind, Tok.isAnnotation() ? "" : PP.getSpelling(Tok), getLangOpts());
[OPENMP 4.5] Sema/parsing support for extended format of 'schedule' clause. OpenMP 4.0-3.1 supports the next format of ‘schedule’ clause: schedule(kind[, chunk_size]) Where kind can be one of ‘static’, ‘dynamic’, ‘guided’, ‘auto’ or ‘runtime’. OpenMP 4.5 defines the format: schedule([modifier [, modifier]:]kind[, chunk_size]) Modifier can be one of ‘monotonic’, ‘nonmonotonic’ or ‘simd’. llvm-svn: 256487
2015-12-28 15:25:51 +08:00
if (KindModifier > OMPC_SCHEDULE_unknown) {
// Parse 'modifier'
Arg[Modifier1] = KindModifier;
KLoc[Modifier1] = Tok.getLocation();
if (Tok.isNot(tok::r_paren) && Tok.isNot(tok::comma) &&
Tok.isNot(tok::annot_pragma_openmp_end))
ConsumeAnyToken();
if (Tok.is(tok::comma)) {
// Parse ',' 'modifier'
ConsumeAnyToken();
KindModifier = getOpenMPSimpleClauseType(
[OpenMP][OpenACC] Implement `ompx_hold` map type modifier extension in Clang (1/2) This patch implements Clang support for an original OpenMP extension we have developed to support OpenACC: the `ompx_hold` map type modifier. The next patch in this series, D106510, implements OpenMP runtime support. Consider the following example: ``` #pragma omp target data map(ompx_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 `ompx_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. (As usual, the standard OpenMP reference count for `x` must also reach zero before the data is unmapped.) Justification for inclusion in Clang and LLVM's OpenMP runtime: * The `ompx_hold` modifier supports OpenACC functionality (structured reference count) that cannot be achieved in standard OpenMP, as of 5.1. * The runtime implementation for `ompx_hold` (next patch) will thus be used by Flang's OpenACC support. * The Clang implementation for `ompx_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 `ompx_hold` is also used by the tests in the runtime implementation. That syntactic support makes the tests more readable than low-level runtime calls can. Moreover, upstream Flang and Clang do not yet support OpenACC syntax sufficiently for writing the tests. * More generally, the Clang implementation enables a clean separation of concerns between OpenACC and OpenMP development in LLVM. That is, LLVM's OpenMP developers can discuss, modify, and debug LLVM's extended OpenMP implementation and test suite without directly considering OpenACC's language and execution model, which can be handled by LLVM's OpenACC developers. * OpenMP users might find the `ompx_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. For example, it explains how the runtime must support two reference counts, as specified by OpenACC. Clang recognizes `ompx_hold` unless `-fno-openmp-extensions`, a new command-line option introduced by this patch, is specified. Reviewed By: ABataev, jdoerfert, protze.joachim, grokos Differential Revision: https://reviews.llvm.org/D106509
2021-09-01 03:17:07 +08:00
Kind, Tok.isAnnotation() ? "" : PP.getSpelling(Tok), getLangOpts());
[OPENMP 4.5] Sema/parsing support for extended format of 'schedule' clause. OpenMP 4.0-3.1 supports the next format of ‘schedule’ clause: schedule(kind[, chunk_size]) Where kind can be one of ‘static’, ‘dynamic’, ‘guided’, ‘auto’ or ‘runtime’. OpenMP 4.5 defines the format: schedule([modifier [, modifier]:]kind[, chunk_size]) Modifier can be one of ‘monotonic’, ‘nonmonotonic’ or ‘simd’. llvm-svn: 256487
2015-12-28 15:25:51 +08:00
Arg[Modifier2] = KindModifier > OMPC_SCHEDULE_unknown
? KindModifier
Silence enumeral and non-enumeral type in conditional expression warning; NFC. llvm-svn: 256501
2015-12-28 23:52:46 +08:00
: (unsigned)OMPC_SCHEDULE_unknown;
[OPENMP 4.5] Sema/parsing support for extended format of 'schedule' clause. OpenMP 4.0-3.1 supports the next format of ‘schedule’ clause: schedule(kind[, chunk_size]) Where kind can be one of ‘static’, ‘dynamic’, ‘guided’, ‘auto’ or ‘runtime’. OpenMP 4.5 defines the format: schedule([modifier [, modifier]:]kind[, chunk_size]) Modifier can be one of ‘monotonic’, ‘nonmonotonic’ or ‘simd’. llvm-svn: 256487
2015-12-28 15:25:51 +08:00
KLoc[Modifier2] = Tok.getLocation();
if (Tok.isNot(tok::r_paren) && Tok.isNot(tok::comma) &&
Tok.isNot(tok::annot_pragma_openmp_end))
ConsumeAnyToken();
}
// Parse ':'
if (Tok.is(tok::colon))
ConsumeAnyToken();
else
Diag(Tok, diag::warn_pragma_expected_colon) << "schedule modifier";
KindModifier = getOpenMPSimpleClauseType(
[OpenMP][OpenACC] Implement `ompx_hold` map type modifier extension in Clang (1/2) This patch implements Clang support for an original OpenMP extension we have developed to support OpenACC: the `ompx_hold` map type modifier. The next patch in this series, D106510, implements OpenMP runtime support. Consider the following example: ``` #pragma omp target data map(ompx_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 `ompx_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. (As usual, the standard OpenMP reference count for `x` must also reach zero before the data is unmapped.) Justification for inclusion in Clang and LLVM's OpenMP runtime: * The `ompx_hold` modifier supports OpenACC functionality (structured reference count) that cannot be achieved in standard OpenMP, as of 5.1. * The runtime implementation for `ompx_hold` (next patch) will thus be used by Flang's OpenACC support. * The Clang implementation for `ompx_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 `ompx_hold` is also used by the tests in the runtime implementation. That syntactic support makes the tests more readable than low-level runtime calls can. Moreover, upstream Flang and Clang do not yet support OpenACC syntax sufficiently for writing the tests. * More generally, the Clang implementation enables a clean separation of concerns between OpenACC and OpenMP development in LLVM. That is, LLVM's OpenMP developers can discuss, modify, and debug LLVM's extended OpenMP implementation and test suite without directly considering OpenACC's language and execution model, which can be handled by LLVM's OpenACC developers. * OpenMP users might find the `ompx_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. For example, it explains how the runtime must support two reference counts, as specified by OpenACC. Clang recognizes `ompx_hold` unless `-fno-openmp-extensions`, a new command-line option introduced by this patch, is specified. Reviewed By: ABataev, jdoerfert, protze.joachim, grokos Differential Revision: https://reviews.llvm.org/D106509
2021-09-01 03:17:07 +08:00
Kind, Tok.isAnnotation() ? "" : PP.getSpelling(Tok), getLangOpts());
[OPENMP 4.5] Sema/parsing support for extended format of 'schedule' clause. OpenMP 4.0-3.1 supports the next format of ‘schedule’ clause: schedule(kind[, chunk_size]) Where kind can be one of ‘static’, ‘dynamic’, ‘guided’, ‘auto’ or ‘runtime’. OpenMP 4.5 defines the format: schedule([modifier [, modifier]:]kind[, chunk_size]) Modifier can be one of ‘monotonic’, ‘nonmonotonic’ or ‘simd’. llvm-svn: 256487
2015-12-28 15:25:51 +08:00
}
Arg[ScheduleKind] = KindModifier;
KLoc[ScheduleKind] = Tok.getLocation();
[OPENMP 4.1] Parsing/sema analysis for extended format of 'if' clause. OpenMP 4.1 added special 'directive-name-modifier' to the 'if' clause. Format of 'if' clause is as follows: ``` if([ directive-name-modifier :] scalar-logical-expression) ``` The restriction rules are also changed. 1. If any 'if' clause on the directive includes a 'directive-name-modifier' then all 'if' clauses on the directive must include a 'directive-name-modifier'. 2. At most one 'if' clause without a 'directive-name-modifier' can appear on the directive. 3. At most one 'if' clause with some particular 'directive-name-modifier' can appear on the directive. 'directive-name-modifier' is important for combined directives and allows to separate conditions in 'if' clause for simple sub-directives in combined directive. This 'directive-name-modifier' identifies the sub-directive to which this 'if' clause must be applied. llvm-svn: 246747
2015-09-03 15:23:48 +08:00
if (Tok.isNot(tok::r_paren) && Tok.isNot(tok::comma) &&
Tok.isNot(tok::annot_pragma_openmp_end))
ConsumeAnyToken();
[OPENMP 4.5] Sema/parsing support for extended format of 'schedule' clause. OpenMP 4.0-3.1 supports the next format of ‘schedule’ clause: schedule(kind[, chunk_size]) Where kind can be one of ‘static’, ‘dynamic’, ‘guided’, ‘auto’ or ‘runtime’. OpenMP 4.5 defines the format: schedule([modifier [, modifier]:]kind[, chunk_size]) Modifier can be one of ‘monotonic’, ‘nonmonotonic’ or ‘simd’. llvm-svn: 256487
2015-12-28 15:25:51 +08:00
if ((Arg[ScheduleKind] == OMPC_SCHEDULE_static ||
Arg[ScheduleKind] == OMPC_SCHEDULE_dynamic ||
Arg[ScheduleKind] == OMPC_SCHEDULE_guided) &&
[OPENMP 4.1] Parsing/sema analysis for extended format of 'if' clause. OpenMP 4.1 added special 'directive-name-modifier' to the 'if' clause. Format of 'if' clause is as follows: ``` if([ directive-name-modifier :] scalar-logical-expression) ``` The restriction rules are also changed. 1. If any 'if' clause on the directive includes a 'directive-name-modifier' then all 'if' clauses on the directive must include a 'directive-name-modifier'. 2. At most one 'if' clause without a 'directive-name-modifier' can appear on the directive. 3. At most one 'if' clause with some particular 'directive-name-modifier' can appear on the directive. 'directive-name-modifier' is important for combined directives and allows to separate conditions in 'if' clause for simple sub-directives in combined directive. This 'directive-name-modifier' identifies the sub-directive to which this 'if' clause must be applied. llvm-svn: 246747
2015-09-03 15:23:48 +08:00
Tok.is(tok::comma))
DelimLoc = ConsumeAnyToken();
Add OpenMP dist_schedule clause to distribute directive and related regression tests. llvm-svn: 257917
2016-01-16 02:50:31 +08:00
} else if (Kind == OMPC_dist_schedule) {
Arg.push_back(getOpenMPSimpleClauseType(
[OpenMP][OpenACC] Implement `ompx_hold` map type modifier extension in Clang (1/2) This patch implements Clang support for an original OpenMP extension we have developed to support OpenACC: the `ompx_hold` map type modifier. The next patch in this series, D106510, implements OpenMP runtime support. Consider the following example: ``` #pragma omp target data map(ompx_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 `ompx_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. (As usual, the standard OpenMP reference count for `x` must also reach zero before the data is unmapped.) Justification for inclusion in Clang and LLVM's OpenMP runtime: * The `ompx_hold` modifier supports OpenACC functionality (structured reference count) that cannot be achieved in standard OpenMP, as of 5.1. * The runtime implementation for `ompx_hold` (next patch) will thus be used by Flang's OpenACC support. * The Clang implementation for `ompx_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 `ompx_hold` is also used by the tests in the runtime implementation. That syntactic support makes the tests more readable than low-level runtime calls can. Moreover, upstream Flang and Clang do not yet support OpenACC syntax sufficiently for writing the tests. * More generally, the Clang implementation enables a clean separation of concerns between OpenACC and OpenMP development in LLVM. That is, LLVM's OpenMP developers can discuss, modify, and debug LLVM's extended OpenMP implementation and test suite without directly considering OpenACC's language and execution model, which can be handled by LLVM's OpenACC developers. * OpenMP users might find the `ompx_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. For example, it explains how the runtime must support two reference counts, as specified by OpenACC. Clang recognizes `ompx_hold` unless `-fno-openmp-extensions`, a new command-line option introduced by this patch, is specified. Reviewed By: ABataev, jdoerfert, protze.joachim, grokos Differential Revision: https://reviews.llvm.org/D106509
2021-09-01 03:17:07 +08:00
Kind, Tok.isAnnotation() ? "" : PP.getSpelling(Tok), getLangOpts()));
Add OpenMP dist_schedule clause to distribute directive and related regression tests. llvm-svn: 257917
2016-01-16 02:50:31 +08:00
KLoc.push_back(Tok.getLocation());
if (Tok.isNot(tok::r_paren) && Tok.isNot(tok::comma) &&
Tok.isNot(tok::annot_pragma_openmp_end))
ConsumeAnyToken();
if (Arg.back() == OMPC_DIST_SCHEDULE_static && Tok.is(tok::comma))
DelimLoc = ConsumeAnyToken();
[OpenMP] Parsing + sema for defaultmap clause. Summary: This patch adds parsing + sema for the defaultmap clause associated with the target directive (among others). Reviewers: ABataev Differential Revision: http://reviews.llvm.org/D16527 llvm-svn: 258817
2016-01-27 00:37:23 +08:00
} else if (Kind == OMPC_defaultmap) {
// Get a defaultmap modifier
[OpenMP 5.0] - Extend defaultmap, by Chi Chun Chen. Summary: For the extended defaultmap, most of the work is inside sema. The only difference for codegen is to set different initial maptype for different implicit-behavior. Reviewers: jdoerfert, ABataev Reviewed By: ABataev Subscribers: dreachem, sandoval, cfe-commits Tags: #clang, #openmp Differential Revision: https://reviews.llvm.org/D69204
2019-11-16 02:02:06 +08:00
unsigned Modifier = getOpenMPSimpleClauseType(
[OpenMP][OpenACC] Implement `ompx_hold` map type modifier extension in Clang (1/2) This patch implements Clang support for an original OpenMP extension we have developed to support OpenACC: the `ompx_hold` map type modifier. The next patch in this series, D106510, implements OpenMP runtime support. Consider the following example: ``` #pragma omp target data map(ompx_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 `ompx_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. (As usual, the standard OpenMP reference count for `x` must also reach zero before the data is unmapped.) Justification for inclusion in Clang and LLVM's OpenMP runtime: * The `ompx_hold` modifier supports OpenACC functionality (structured reference count) that cannot be achieved in standard OpenMP, as of 5.1. * The runtime implementation for `ompx_hold` (next patch) will thus be used by Flang's OpenACC support. * The Clang implementation for `ompx_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 `ompx_hold` is also used by the tests in the runtime implementation. That syntactic support makes the tests more readable than low-level runtime calls can. Moreover, upstream Flang and Clang do not yet support OpenACC syntax sufficiently for writing the tests. * More generally, the Clang implementation enables a clean separation of concerns between OpenACC and OpenMP development in LLVM. That is, LLVM's OpenMP developers can discuss, modify, and debug LLVM's extended OpenMP implementation and test suite without directly considering OpenACC's language and execution model, which can be handled by LLVM's OpenACC developers. * OpenMP users might find the `ompx_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. For example, it explains how the runtime must support two reference counts, as specified by OpenACC. Clang recognizes `ompx_hold` unless `-fno-openmp-extensions`, a new command-line option introduced by this patch, is specified. Reviewed By: ABataev, jdoerfert, protze.joachim, grokos Differential Revision: https://reviews.llvm.org/D106509
2021-09-01 03:17:07 +08:00
Kind, Tok.isAnnotation() ? "" : PP.getSpelling(Tok), getLangOpts());
[OpenMP 5.0] - Extend defaultmap, by Chi Chun Chen. Summary: For the extended defaultmap, most of the work is inside sema. The only difference for codegen is to set different initial maptype for different implicit-behavior. Reviewers: jdoerfert, ABataev Reviewed By: ABataev Subscribers: dreachem, sandoval, cfe-commits Tags: #clang, #openmp Differential Revision: https://reviews.llvm.org/D69204
2019-11-16 02:02:06 +08:00
// Set defaultmap modifier to unknown if it is either scalar, aggregate, or
// pointer
if (Modifier < OMPC_DEFAULTMAP_MODIFIER_unknown)
Modifier = OMPC_DEFAULTMAP_MODIFIER_unknown;
Arg.push_back(Modifier);
[OpenMP] Parsing + sema for defaultmap clause. Summary: This patch adds parsing + sema for the defaultmap clause associated with the target directive (among others). Reviewers: ABataev Differential Revision: http://reviews.llvm.org/D16527 llvm-svn: 258817
2016-01-27 00:37:23 +08:00
KLoc.push_back(Tok.getLocation());
if (Tok.isNot(tok::r_paren) && Tok.isNot(tok::comma) &&
Tok.isNot(tok::annot_pragma_openmp_end))
ConsumeAnyToken();
// Parse ':'
[OPENMP50] Fix PR45469: Consider variable-category of defaultmap clause as optional. Summary: According to the standard, variable-category is the optional part of the defaultmap clause while the compiler always requires it. Turned it into optional part. Reviewers: jdoerfert Subscribers: yaxunl, guansong, cfe-commits, caomhin Tags: #clang Differential Revision: https://reviews.llvm.org/D77751
2020-04-09 03:19:54 +08:00
if (Tok.is(tok::colon) || getLangOpts().OpenMP < 50) {
if (Tok.is(tok::colon))
ConsumeAnyToken();
else if (Arg.back() != OMPC_DEFAULTMAP_MODIFIER_unknown)
Diag(Tok, diag::warn_pragma_expected_colon) << "defaultmap modifier";
// Get a defaultmap kind
Arg.push_back(getOpenMPSimpleClauseType(
[OpenMP][OpenACC] Implement `ompx_hold` map type modifier extension in Clang (1/2) This patch implements Clang support for an original OpenMP extension we have developed to support OpenACC: the `ompx_hold` map type modifier. The next patch in this series, D106510, implements OpenMP runtime support. Consider the following example: ``` #pragma omp target data map(ompx_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 `ompx_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. (As usual, the standard OpenMP reference count for `x` must also reach zero before the data is unmapped.) Justification for inclusion in Clang and LLVM's OpenMP runtime: * The `ompx_hold` modifier supports OpenACC functionality (structured reference count) that cannot be achieved in standard OpenMP, as of 5.1. * The runtime implementation for `ompx_hold` (next patch) will thus be used by Flang's OpenACC support. * The Clang implementation for `ompx_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 `ompx_hold` is also used by the tests in the runtime implementation. That syntactic support makes the tests more readable than low-level runtime calls can. Moreover, upstream Flang and Clang do not yet support OpenACC syntax sufficiently for writing the tests. * More generally, the Clang implementation enables a clean separation of concerns between OpenACC and OpenMP development in LLVM. That is, LLVM's OpenMP developers can discuss, modify, and debug LLVM's extended OpenMP implementation and test suite without directly considering OpenACC's language and execution model, which can be handled by LLVM's OpenACC developers. * OpenMP users might find the `ompx_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. For example, it explains how the runtime must support two reference counts, as specified by OpenACC. Clang recognizes `ompx_hold` unless `-fno-openmp-extensions`, a new command-line option introduced by this patch, is specified. Reviewed By: ABataev, jdoerfert, protze.joachim, grokos Differential Revision: https://reviews.llvm.org/D106509
2021-09-01 03:17:07 +08:00
Kind, Tok.isAnnotation() ? "" : PP.getSpelling(Tok), getLangOpts()));
[OPENMP50] Fix PR45469: Consider variable-category of defaultmap clause as optional. Summary: According to the standard, variable-category is the optional part of the defaultmap clause while the compiler always requires it. Turned it into optional part. Reviewers: jdoerfert Subscribers: yaxunl, guansong, cfe-commits, caomhin Tags: #clang Differential Revision: https://reviews.llvm.org/D77751
2020-04-09 03:19:54 +08:00
KLoc.push_back(Tok.getLocation());
if (Tok.isNot(tok::r_paren) && Tok.isNot(tok::comma) &&
Tok.isNot(tok::annot_pragma_openmp_end))
ConsumeAnyToken();
} else {
Arg.push_back(OMPC_DEFAULTMAP_unknown);
KLoc.push_back(SourceLocation());
}
[OPENMP50]Add support for extended device clause in target directives. Added parsing/sema/serialization support for extended device clause in executable target directives.
2020-03-19 03:01:15 +08:00
} else if (Kind == OMPC_device) {
// Only target executable directives support extended device construct.
if (isOpenMPTargetExecutionDirective(DKind) && getLangOpts().OpenMP >= 50 &&
NextToken().is(tok::colon)) {
// Parse optional <device modifier> ':'
Arg.push_back(getOpenMPSimpleClauseType(
[OpenMP][OpenACC] Implement `ompx_hold` map type modifier extension in Clang (1/2) This patch implements Clang support for an original OpenMP extension we have developed to support OpenACC: the `ompx_hold` map type modifier. The next patch in this series, D106510, implements OpenMP runtime support. Consider the following example: ``` #pragma omp target data map(ompx_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 `ompx_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. (As usual, the standard OpenMP reference count for `x` must also reach zero before the data is unmapped.) Justification for inclusion in Clang and LLVM's OpenMP runtime: * The `ompx_hold` modifier supports OpenACC functionality (structured reference count) that cannot be achieved in standard OpenMP, as of 5.1. * The runtime implementation for `ompx_hold` (next patch) will thus be used by Flang's OpenACC support. * The Clang implementation for `ompx_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 `ompx_hold` is also used by the tests in the runtime implementation. That syntactic support makes the tests more readable than low-level runtime calls can. Moreover, upstream Flang and Clang do not yet support OpenACC syntax sufficiently for writing the tests. * More generally, the Clang implementation enables a clean separation of concerns between OpenACC and OpenMP development in LLVM. That is, LLVM's OpenMP developers can discuss, modify, and debug LLVM's extended OpenMP implementation and test suite without directly considering OpenACC's language and execution model, which can be handled by LLVM's OpenACC developers. * OpenMP users might find the `ompx_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. For example, it explains how the runtime must support two reference counts, as specified by OpenACC. Clang recognizes `ompx_hold` unless `-fno-openmp-extensions`, a new command-line option introduced by this patch, is specified. Reviewed By: ABataev, jdoerfert, protze.joachim, grokos Differential Revision: https://reviews.llvm.org/D106509
2021-09-01 03:17:07 +08:00
Kind, Tok.isAnnotation() ? "" : PP.getSpelling(Tok), getLangOpts()));
[OPENMP50]Add support for extended device clause in target directives. Added parsing/sema/serialization support for extended device clause in executable target directives.
2020-03-19 03:01:15 +08:00
KLoc.push_back(Tok.getLocation());
ConsumeAnyToken();
// Parse ':'
ConsumeAnyToken();
} else {
Arg.push_back(OMPC_DEVICE_unknown);
KLoc.emplace_back();
}
[OPENMP 4.1] Parsing/sema analysis for extended format of 'if' clause. OpenMP 4.1 added special 'directive-name-modifier' to the 'if' clause. Format of 'if' clause is as follows: ``` if([ directive-name-modifier :] scalar-logical-expression) ``` The restriction rules are also changed. 1. If any 'if' clause on the directive includes a 'directive-name-modifier' then all 'if' clauses on the directive must include a 'directive-name-modifier'. 2. At most one 'if' clause without a 'directive-name-modifier' can appear on the directive. 3. At most one 'if' clause with some particular 'directive-name-modifier' can appear on the directive. 'directive-name-modifier' is important for combined directives and allows to separate conditions in 'if' clause for simple sub-directives in combined directive. This 'directive-name-modifier' identifies the sub-directive to which this 'if' clause must be applied. llvm-svn: 246747
2015-09-03 15:23:48 +08:00
} else {
assert(Kind == OMPC_if);
[OPENMP 4.5] Sema/parsing support for extended format of 'schedule' clause. OpenMP 4.0-3.1 supports the next format of ‘schedule’ clause: schedule(kind[, chunk_size]) Where kind can be one of ‘static’, ‘dynamic’, ‘guided’, ‘auto’ or ‘runtime’. OpenMP 4.5 defines the format: schedule([modifier [, modifier]:]kind[, chunk_size]) Modifier can be one of ‘monotonic’, ‘nonmonotonic’ or ‘simd’. llvm-svn: 256487
2015-12-28 15:25:51 +08:00
KLoc.push_back(Tok.getLocation());
[OPENMP] Fix for PR31428: variable named like directive name modifier Directive name modifiers in 'if' clause are allowed only for OpenMP 4.5 and higher + in OpenMP 4.5 parsing procedure emits error message if ':' is not found after directive name modifier. llvm-svn: 290175
2016-12-20 20:10:05 +08:00
TentativeParsingAction TPA(*this);
[OpenMP][NFCI] Introduce llvm/IR/OpenMPConstants.h Summary: The new OpenMPConstants.h is a location for all OpenMP related constants (and helpers) to live. This patch moves the directives there (the enum OpenMPDirectiveKind) and rewires Clang to use the new location. Initially part of D69785. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: jholewinski, ppenzin, penzn, llvm-commits, cfe-commits, jfb, guansong, bollu, hiraditya, mgorny Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D69853
2019-11-05 12:00:49 +08:00
auto DK = parseOpenMPDirectiveKind(*this);
Arg.push_back(DK);
if (DK != OMPD_unknown) {
[OPENMP 4.1] Parsing/sema analysis for extended format of 'if' clause. OpenMP 4.1 added special 'directive-name-modifier' to the 'if' clause. Format of 'if' clause is as follows: ``` if([ directive-name-modifier :] scalar-logical-expression) ``` The restriction rules are also changed. 1. If any 'if' clause on the directive includes a 'directive-name-modifier' then all 'if' clauses on the directive must include a 'directive-name-modifier'. 2. At most one 'if' clause without a 'directive-name-modifier' can appear on the directive. 3. At most one 'if' clause with some particular 'directive-name-modifier' can appear on the directive. 'directive-name-modifier' is important for combined directives and allows to separate conditions in 'if' clause for simple sub-directives in combined directive. This 'directive-name-modifier' identifies the sub-directive to which this 'if' clause must be applied. llvm-svn: 246747
2015-09-03 15:23:48 +08:00
ConsumeToken();
[OPENMP] Fix for PR31428: variable named like directive name modifier Directive name modifiers in 'if' clause are allowed only for OpenMP 4.5 and higher + in OpenMP 4.5 parsing procedure emits error message if ':' is not found after directive name modifier. llvm-svn: 290175
2016-12-20 20:10:05 +08:00
if (Tok.is(tok::colon) && getLangOpts().OpenMP > 40) {
TPA.Commit();
[OPENMP 4.1] Parsing/sema analysis for extended format of 'if' clause. OpenMP 4.1 added special 'directive-name-modifier' to the 'if' clause. Format of 'if' clause is as follows: ``` if([ directive-name-modifier :] scalar-logical-expression) ``` The restriction rules are also changed. 1. If any 'if' clause on the directive includes a 'directive-name-modifier' then all 'if' clauses on the directive must include a 'directive-name-modifier'. 2. At most one 'if' clause without a 'directive-name-modifier' can appear on the directive. 3. At most one 'if' clause with some particular 'directive-name-modifier' can appear on the directive. 'directive-name-modifier' is important for combined directives and allows to separate conditions in 'if' clause for simple sub-directives in combined directive. This 'directive-name-modifier' identifies the sub-directive to which this 'if' clause must be applied. llvm-svn: 246747
2015-09-03 15:23:48 +08:00
DelimLoc = ConsumeToken();
[OPENMP] Fix for PR31428: variable named like directive name modifier Directive name modifiers in 'if' clause are allowed only for OpenMP 4.5 and higher + in OpenMP 4.5 parsing procedure emits error message if ':' is not found after directive name modifier. llvm-svn: 290175
2016-12-20 20:10:05 +08:00
} else {
TPA.Revert();
[OpenMP][NFCI] Introduce llvm/IR/OpenMPConstants.h Summary: The new OpenMPConstants.h is a location for all OpenMP related constants (and helpers) to live. This patch moves the directives there (the enum OpenMPDirectiveKind) and rewires Clang to use the new location. Initially part of D69785. Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: jholewinski, ppenzin, penzn, llvm-commits, cfe-commits, jfb, guansong, bollu, hiraditya, mgorny Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D69853
2019-11-05 12:00:49 +08:00
Arg.back() = unsigned(OMPD_unknown);
[OPENMP] Fix for PR31428: variable named like directive name modifier Directive name modifiers in 'if' clause are allowed only for OpenMP 4.5 and higher + in OpenMP 4.5 parsing procedure emits error message if ':' is not found after directive name modifier. llvm-svn: 290175
2016-12-20 20:10:05 +08:00
}
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-24 03:53:05 +08:00
} else {
[OPENMP] Fix for PR31428: variable named like directive name modifier Directive name modifiers in 'if' clause are allowed only for OpenMP 4.5 and higher + in OpenMP 4.5 parsing procedure emits error message if ':' is not found after directive name modifier. llvm-svn: 290175
2016-12-20 20:10:05 +08:00
TPA.Revert();
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-24 03:53:05 +08:00
}
[OPENMP 4.1] Parsing/sema analysis for extended format of 'if' clause. OpenMP 4.1 added special 'directive-name-modifier' to the 'if' clause. Format of 'if' clause is as follows: ``` if([ directive-name-modifier :] scalar-logical-expression) ``` The restriction rules are also changed. 1. If any 'if' clause on the directive includes a 'directive-name-modifier' then all 'if' clauses on the directive must include a 'directive-name-modifier'. 2. At most one 'if' clause without a 'directive-name-modifier' can appear on the directive. 3. At most one 'if' clause with some particular 'directive-name-modifier' can appear on the directive. 'directive-name-modifier' is important for combined directives and allows to separate conditions in 'if' clause for simple sub-directives in combined directive. This 'directive-name-modifier' identifies the sub-directive to which this 'if' clause must be applied. llvm-svn: 246747
2015-09-03 15:23:48 +08:00
}
[OPENMP] Initial support for 'schedule' clause. llvm-svn: 211342
2014-06-20 15:16:17 +08:00
Add OpenMP dist_schedule clause to distribute directive and related regression tests. llvm-svn: 257917
2016-01-16 02:50:31 +08:00
bool NeedAnExpression = (Kind == OMPC_schedule && DelimLoc.isValid()) ||
(Kind == OMPC_dist_schedule && DelimLoc.isValid()) ||
[OPENMP50]Add support for extended device clause in target directives. Added parsing/sema/serialization support for extended device clause in executable target directives.
2020-03-19 03:01:15 +08:00
Kind == OMPC_if || Kind == OMPC_device;
[OPENMP 4.1] Parsing/sema analysis for extended format of 'if' clause. OpenMP 4.1 added special 'directive-name-modifier' to the 'if' clause. Format of 'if' clause is as follows: ``` if([ directive-name-modifier :] scalar-logical-expression) ``` The restriction rules are also changed. 1. If any 'if' clause on the directive includes a 'directive-name-modifier' then all 'if' clauses on the directive must include a 'directive-name-modifier'. 2. At most one 'if' clause without a 'directive-name-modifier' can appear on the directive. 3. At most one 'if' clause with some particular 'directive-name-modifier' can appear on the directive. 'directive-name-modifier' is important for combined directives and allows to separate conditions in 'if' clause for simple sub-directives in combined directive. This 'directive-name-modifier' identifies the sub-directive to which this 'if' clause must be applied. llvm-svn: 246747
2015-09-03 15:23:48 +08:00
if (NeedAnExpression) {
SourceLocation ELoc = Tok.getLocation();
[Concepts] Function trailing requires clauses Function trailing requires clauses now parsed, supported in overload resolution and when calling, referencing and taking the address of functions or function templates. Differential Revision: https://reviews.llvm.org/D43357
2020-01-09 21:07:51 +08:00
ExprResult LHS(ParseCastExpression(AnyCastExpr, false, NotTypeCast));
[OPENMP] Initial support for 'schedule' clause. llvm-svn: 211342
2014-06-20 15:16:17 +08:00
Val = ParseRHSOfBinaryExpression(LHS, prec::Conditional);
Refactor the way we handle diagnosing unused expression results. Rather than sprinkle calls to DiagnoseUnusedExprResult() around in places where we want diagnostics, we now diagnose unused expression statements and full expressions in a more generic way when acting on the final expression statement. This results in more appropriate diagnostics for [[nodiscard]] where we were previously lacking them, such as when the body of a for loop is not a compound statement. This patch fixes PR39837. llvm-svn: 350404
2019-01-05 00:58:14 +08:00
Val =
Actions.ActOnFinishFullExpr(Val.get(), ELoc, /*DiscardedValue*/ false);
[OPENMP] Initial support for 'schedule' clause. llvm-svn: 211342
2014-06-20 15:16:17 +08:00
}
// Parse ')'.
[OPENMP] Make clauses closing loc point to right bracket. For some of the clauses the closing location erroneously points to the beginning of the next clause rather than on the location of the closing bracket of the clause. llvm-svn: 336460
2018-07-07 03:35:42 +08:00
SourceLocation RLoc = Tok.getLocation();
if (!T.consumeClose())
RLoc = T.getCloseLocation();
[OPENMP] Initial support for 'schedule' clause. llvm-svn: 211342
2014-06-20 15:16:17 +08:00
[OPENMP 4.1] Parsing/sema analysis for extended format of 'if' clause. OpenMP 4.1 added special 'directive-name-modifier' to the 'if' clause. Format of 'if' clause is as follows: ``` if([ directive-name-modifier :] scalar-logical-expression) ``` The restriction rules are also changed. 1. If any 'if' clause on the directive includes a 'directive-name-modifier' then all 'if' clauses on the directive must include a 'directive-name-modifier'. 2. At most one 'if' clause without a 'directive-name-modifier' can appear on the directive. 3. At most one 'if' clause with some particular 'directive-name-modifier' can appear on the directive. 'directive-name-modifier' is important for combined directives and allows to separate conditions in 'if' clause for simple sub-directives in combined directive. This 'directive-name-modifier' identifies the sub-directive to which this 'if' clause must be applied. llvm-svn: 246747
2015-09-03 15:23:48 +08:00
if (NeedAnExpression && Val.isInvalid())
return nullptr;
[OpenMP] Fix handling of clause on wrong directive, by Joel. E. Denny Summary: First, this patch fixes an assert failure when, for example, "omp for" has num_teams. Second, this patch prevents duplicate diagnostics when, for example, "omp for" has uniform. This patch makes the general assumption (even where it doesn't necessarily fix an existing bug) that it is worthless to perform sema for a clause that appears on a directive on which OpenMP does not permit that clause. However, due to this assumption, this patch suppresses some diagnostics that were expected in the test suite. I assert that those diagnostics were likely just distracting to the user. Reviewers: ABataev Reviewed By: ABataev Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D41841 llvm-svn: 322107
2018-01-10 03:21:04 +08:00
if (ParseOnly)
return nullptr;
[OPENMP] Initial support for 'schedule' clause. llvm-svn: 211342
2014-06-20 15:16:17 +08:00
return Actions.ActOnOpenMPSingleExprWithArgClause(
[OPENMP] Make clauses closing loc point to right bracket. For some of the clauses the closing location erroneously points to the beginning of the next clause rather than on the location of the closing bracket of the clause. llvm-svn: 336460
2018-07-07 03:35:42 +08:00
Kind, Arg, Val.get(), Loc, T.getOpenLocation(), KLoc, DelimLoc, RLoc);
[OPENMP] Initial support for 'schedule' clause. llvm-svn: 211342
2014-06-20 15:16:17 +08:00
}
[OPENMP] Initial support of 'reduction' clause llvm-svn: 211007
2014-06-16 15:08:35 +08:00
static bool ParseReductionId(Parser &P, CXXScopeSpec &ReductionIdScopeSpec,
UnqualifiedId &ReductionId) {
if (ReductionIdScopeSpec.isEmpty()) {
auto OOK = OO_None;
switch (P.getCurToken().getKind()) {
case tok::plus:
OOK = OO_Plus;
break;
case tok::minus:
OOK = OO_Minus;
break;
case tok::star:
OOK = OO_Star;
break;
case tok::amp:
OOK = OO_Amp;
break;
case tok::pipe:
OOK = OO_Pipe;
break;
case tok::caret:
OOK = OO_Caret;
break;
case tok::ampamp:
OOK = OO_AmpAmp;
break;
case tok::pipepipe:
OOK = OO_PipePipe;
break;
default:
break;
}
if (OOK != OO_None) {
SourceLocation OpLoc = P.ConsumeToken();
[OPENMP] Reformatting and code improvement. llvm-svn: 211147
2014-06-18 15:08:49 +08:00
SourceLocation SymbolLocations[] = {OpLoc, OpLoc, SourceLocation()};
[OPENMP] Initial support of 'reduction' clause llvm-svn: 211007
2014-06-16 15:08:35 +08:00
ReductionId.setOperatorFunctionId(OpLoc, OOK, SymbolLocations);
return false;
}
}
[Parser] Avoid spurious 'missing template' error in presence of typos. Suppress those diagnostics if lhs of a member expression contains errors. Typo correction produces dependent expressions even in non-template code, that led to spurious diagnostics before. previous: /tmp/t.cpp:6:17: error: use 'template' keyword to treat 'f' as a dependent template name auto a = bilder.f<int>(); ^ template /tmp/t.cpp:6:10: error: use of undeclared identifier 'bilder'; did you mean 'builder'? auto a = bilder.f<int>(); ^~~~~~ builder vs now: /tmp/t.cpp:6:10: error: use of undeclared identifier 'bilder'; did you mean 'builder'? auto a = bilder.f<int>(); ^~~~~~ builder Original patch from Ilya. Reviewers: sammccall Reviewed By: sammccall Tags: #clang Differential Revision: https://reviews.llvm.org/D65592
2020-03-19 16:12:29 +08:00
return P.ParseUnqualifiedId(
ReductionIdScopeSpec, /*ObjectType=*/nullptr,
/*ObjectHadErrors=*/false, /*EnteringContext*/ false,
/*AllowDestructorName*/ false,
/*AllowConstructorName*/ false,
/*AllowDeductionGuide*/ false, nullptr, ReductionId);
[OPENMP] Initial support of 'reduction' clause llvm-svn: 211007
2014-06-16 15:08:35 +08:00
}
[OPENMP] parsing and sema support for 'close' map-type-modifier A map clause with the close map-type-modifier is a hint to prefer that the variables are mapped using a copy into faster memory. Patch by Ahsan Saghir (saghir) Differential Revision: https://reviews.llvm.org/D55719 llvm-svn: 349551
2018-12-19 06:18:41 +08:00
/// Checks if the token is a valid map-type-modifier.
[OpenMP] Implement TR8 `present` map type modifier in Clang (1/2) This patch implements Clang front end support for the OpenMP TR8 `present` map type modifier. The next patch in this series implements OpenMP runtime support. This patch does not attempt to implement TR8 sec. 2.22.7.1 "map Clause", p. 319, L14-16: > If a map clause with a present map-type-modifier is present in a map > clause, then the effect of the clause is ordered before all other > map clauses that do not have the present modifier. Compare to L10-11, which Clang does not appear to implement yet: > For a given construct, the effect of a map clause with the to, from, > or tofrom map-type is ordered before the effect of a map clause with > the alloc, release, or delete map-type. This patch also does not implement the `present` implicit-behavior for `defaultmap` or the `present` motion-modifier for `target update`. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D83061
2020-07-22 22:14:00 +08:00
/// FIXME: It will return an OpenMPMapClauseKind if that's what it parses.
[OPENMP] parsing and sema support for 'close' map-type-modifier A map clause with the close map-type-modifier is a hint to prefer that the variables are mapped using a copy into faster memory. Patch by Ahsan Saghir (saghir) Differential Revision: https://reviews.llvm.org/D55719 llvm-svn: 349551
2018-12-19 06:18:41 +08:00
static OpenMPMapModifierKind isMapModifier(Parser &P) {
Token Tok = P.getCurToken();
if (!Tok.is(tok::identifier))
return OMPC_MAP_MODIFIER_unknown;
Preprocessor &PP = P.getPreprocessor();
[OpenMP] Implement TR8 `present` map type modifier in Clang (1/2) This patch implements Clang front end support for the OpenMP TR8 `present` map type modifier. The next patch in this series implements OpenMP runtime support. This patch does not attempt to implement TR8 sec. 2.22.7.1 "map Clause", p. 319, L14-16: > If a map clause with a present map-type-modifier is present in a map > clause, then the effect of the clause is ordered before all other > map clauses that do not have the present modifier. Compare to L10-11, which Clang does not appear to implement yet: > For a given construct, the effect of a map clause with the to, from, > or tofrom map-type is ordered before the effect of a map clause with > the alloc, release, or delete map-type. This patch also does not implement the `present` implicit-behavior for `defaultmap` or the `present` motion-modifier for `target update`. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D83061
2020-07-22 22:14:00 +08:00
OpenMPMapModifierKind TypeModifier =
static_cast<OpenMPMapModifierKind>(getOpenMPSimpleClauseType(
[OpenMP][OpenACC] Implement `ompx_hold` map type modifier extension in Clang (1/2) This patch implements Clang support for an original OpenMP extension we have developed to support OpenACC: the `ompx_hold` map type modifier. The next patch in this series, D106510, implements OpenMP runtime support. Consider the following example: ``` #pragma omp target data map(ompx_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 `ompx_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. (As usual, the standard OpenMP reference count for `x` must also reach zero before the data is unmapped.) Justification for inclusion in Clang and LLVM's OpenMP runtime: * The `ompx_hold` modifier supports OpenACC functionality (structured reference count) that cannot be achieved in standard OpenMP, as of 5.1. * The runtime implementation for `ompx_hold` (next patch) will thus be used by Flang's OpenACC support. * The Clang implementation for `ompx_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 `ompx_hold` is also used by the tests in the runtime implementation. That syntactic support makes the tests more readable than low-level runtime calls can. Moreover, upstream Flang and Clang do not yet support OpenACC syntax sufficiently for writing the tests. * More generally, the Clang implementation enables a clean separation of concerns between OpenACC and OpenMP development in LLVM. That is, LLVM's OpenMP developers can discuss, modify, and debug LLVM's extended OpenMP implementation and test suite without directly considering OpenACC's language and execution model, which can be handled by LLVM's OpenACC developers. * OpenMP users might find the `ompx_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. For example, it explains how the runtime must support two reference counts, as specified by OpenACC. Clang recognizes `ompx_hold` unless `-fno-openmp-extensions`, a new command-line option introduced by this patch, is specified. Reviewed By: ABataev, jdoerfert, protze.joachim, grokos Differential Revision: https://reviews.llvm.org/D106509
2021-09-01 03:17:07 +08:00
OMPC_map, PP.getSpelling(Tok), P.getLangOpts()));
[OPENMP] parsing and sema support for 'close' map-type-modifier A map clause with the close map-type-modifier is a hint to prefer that the variables are mapped using a copy into faster memory. Patch by Ahsan Saghir (saghir) Differential Revision: https://reviews.llvm.org/D55719 llvm-svn: 349551
2018-12-19 06:18:41 +08:00
return TypeModifier;
}
[OpenMP 5.0] Parsing/sema support for to clause with mapper modifier. This patch implements the parsing and sema support for OpenMP to clause with potential user-defined mappers attached. User defined mapper is a new feature in OpenMP 5.0. A to/from clause can have an explicit or implicit associated mapper, which instructs the compiler to generate and use customized mapping functions. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target update to(mapper(id): ss) // use the mapper with name 'id' to map ss to device Contributed-by: <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58523 llvm-svn: 354698
2019-02-23 06:29:42 +08:00
/// Parse the mapper modifier in map, to, and from clauses.
bool Parser::parseMapperModifier(OpenMPVarListDataTy &Data) {
// Parse '('.
BalancedDelimiterTracker T(*this, tok::l_paren, tok::colon);
if (T.expectAndConsume(diag::err_expected_lparen_after, "mapper")) {
SkipUntil(tok::colon, tok::r_paren, tok::annot_pragma_openmp_end,
StopBeforeMatch);
return true;
}
// Parse mapper-identifier
if (getLangOpts().CPlusPlus)
ParseOptionalCXXScopeSpecifier(Data.ReductionOrMapperIdScopeSpec,
/*ObjectType=*/nullptr,
[Parser] Avoid spurious 'missing template' error in presence of typos. Suppress those diagnostics if lhs of a member expression contains errors. Typo correction produces dependent expressions even in non-template code, that led to spurious diagnostics before. previous: /tmp/t.cpp:6:17: error: use 'template' keyword to treat 'f' as a dependent template name auto a = bilder.f<int>(); ^ template /tmp/t.cpp:6:10: error: use of undeclared identifier 'bilder'; did you mean 'builder'? auto a = bilder.f<int>(); ^~~~~~ builder vs now: /tmp/t.cpp:6:10: error: use of undeclared identifier 'bilder'; did you mean 'builder'? auto a = bilder.f<int>(); ^~~~~~ builder Original patch from Ilya. Reviewers: sammccall Reviewed By: sammccall Tags: #clang Differential Revision: https://reviews.llvm.org/D65592
2020-03-19 16:12:29 +08:00
/*ObjectHadErrors=*/false,
[OpenMP 5.0] Parsing/sema support for to clause with mapper modifier. This patch implements the parsing and sema support for OpenMP to clause with potential user-defined mappers attached. User defined mapper is a new feature in OpenMP 5.0. A to/from clause can have an explicit or implicit associated mapper, which instructs the compiler to generate and use customized mapping functions. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target update to(mapper(id): ss) // use the mapper with name 'id' to map ss to device Contributed-by: <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58523 llvm-svn: 354698
2019-02-23 06:29:42 +08:00
/*EnteringContext=*/false);
if (Tok.isNot(tok::identifier) && Tok.isNot(tok::kw_default)) {
Diag(Tok.getLocation(), diag::err_omp_mapper_illegal_identifier);
SkipUntil(tok::colon, tok::r_paren, tok::annot_pragma_openmp_end,
StopBeforeMatch);
return true;
}
auto &DeclNames = Actions.getASTContext().DeclarationNames;
Data.ReductionOrMapperId = DeclarationNameInfo(
DeclNames.getIdentifier(Tok.getIdentifierInfo()), Tok.getLocation());
ConsumeToken();
// Parse ')'.
return T.consumeClose();
}
[OPENMP] parsing and sema support for 'close' map-type-modifier A map clause with the close map-type-modifier is a hint to prefer that the variables are mapped using a copy into faster memory. Patch by Ahsan Saghir (saghir) Differential Revision: https://reviews.llvm.org/D55719 llvm-svn: 349551
2018-12-19 06:18:41 +08:00
/// Parse map-type-modifiers in map clause.
/// map([ [map-type-modifier[,] [map-type-modifier[,] ...] map-type : ] list)
[OpenMP] Implement TR8 `present` map type modifier in Clang (1/2) This patch implements Clang front end support for the OpenMP TR8 `present` map type modifier. The next patch in this series implements OpenMP runtime support. This patch does not attempt to implement TR8 sec. 2.22.7.1 "map Clause", p. 319, L14-16: > If a map clause with a present map-type-modifier is present in a map > clause, then the effect of the clause is ordered before all other > map clauses that do not have the present modifier. Compare to L10-11, which Clang does not appear to implement yet: > For a given construct, the effect of a map clause with the to, from, > or tofrom map-type is ordered before the effect of a map clause with > the alloc, release, or delete map-type. This patch also does not implement the `present` implicit-behavior for `defaultmap` or the `present` motion-modifier for `target update`. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D83061
2020-07-22 22:14:00 +08:00
/// where, map-type-modifier ::= always | close | mapper(mapper-identifier) |
/// present
[OpenMP 5.0] Parsing/sema support for map clause with mapper modifier. This patch implements the parsing and sema support for OpenMP map clauses with potential user-defined mapper attached. User defined mapper is a new feature in OpenMP 5.0. A map clause can have an explicit or implicit associated mapper, which instructs the compiler to generate extra data mapping. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target map(mapper(id) tofrom: ss) // use the mapper with name 'id' to map ss Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58074 llvm-svn: 354347
2019-02-20 00:38:20 +08:00
bool Parser::parseMapTypeModifiers(OpenMPVarListDataTy &Data) {
while (getCurToken().isNot(tok::colon)) {
OpenMPMapModifierKind TypeModifier = isMapModifier(*this);
[OPENMP] parsing and sema support for 'close' map-type-modifier A map clause with the close map-type-modifier is a hint to prefer that the variables are mapped using a copy into faster memory. Patch by Ahsan Saghir (saghir) Differential Revision: https://reviews.llvm.org/D55719 llvm-svn: 349551
2018-12-19 06:18:41 +08:00
if (TypeModifier == OMPC_MAP_MODIFIER_always ||
[OpenMP] Implement TR8 `present` map type modifier in Clang (1/2) This patch implements Clang front end support for the OpenMP TR8 `present` map type modifier. The next patch in this series implements OpenMP runtime support. This patch does not attempt to implement TR8 sec. 2.22.7.1 "map Clause", p. 319, L14-16: > If a map clause with a present map-type-modifier is present in a map > clause, then the effect of the clause is ordered before all other > map clauses that do not have the present modifier. Compare to L10-11, which Clang does not appear to implement yet: > For a given construct, the effect of a map clause with the to, from, > or tofrom map-type is ordered before the effect of a map clause with > the alloc, release, or delete map-type. This patch also does not implement the `present` implicit-behavior for `defaultmap` or the `present` motion-modifier for `target update`. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D83061
2020-07-22 22:14:00 +08:00
TypeModifier == OMPC_MAP_MODIFIER_close ||
[OpenMP][OpenACC] Implement `ompx_hold` map type modifier extension in Clang (1/2) This patch implements Clang support for an original OpenMP extension we have developed to support OpenACC: the `ompx_hold` map type modifier. The next patch in this series, D106510, implements OpenMP runtime support. Consider the following example: ``` #pragma omp target data map(ompx_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 `ompx_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. (As usual, the standard OpenMP reference count for `x` must also reach zero before the data is unmapped.) Justification for inclusion in Clang and LLVM's OpenMP runtime: * The `ompx_hold` modifier supports OpenACC functionality (structured reference count) that cannot be achieved in standard OpenMP, as of 5.1. * The runtime implementation for `ompx_hold` (next patch) will thus be used by Flang's OpenACC support. * The Clang implementation for `ompx_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 `ompx_hold` is also used by the tests in the runtime implementation. That syntactic support makes the tests more readable than low-level runtime calls can. Moreover, upstream Flang and Clang do not yet support OpenACC syntax sufficiently for writing the tests. * More generally, the Clang implementation enables a clean separation of concerns between OpenACC and OpenMP development in LLVM. That is, LLVM's OpenMP developers can discuss, modify, and debug LLVM's extended OpenMP implementation and test suite without directly considering OpenACC's language and execution model, which can be handled by LLVM's OpenACC developers. * OpenMP users might find the `ompx_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. For example, it explains how the runtime must support two reference counts, as specified by OpenACC. Clang recognizes `ompx_hold` unless `-fno-openmp-extensions`, a new command-line option introduced by this patch, is specified. Reviewed By: ABataev, jdoerfert, protze.joachim, grokos Differential Revision: https://reviews.llvm.org/D106509
2021-09-01 03:17:07 +08:00
TypeModifier == OMPC_MAP_MODIFIER_present ||
TypeModifier == OMPC_MAP_MODIFIER_ompx_hold) {
[OPENMP] parsing and sema support for 'close' map-type-modifier A map clause with the close map-type-modifier is a hint to prefer that the variables are mapped using a copy into faster memory. Patch by Ahsan Saghir (saghir) Differential Revision: https://reviews.llvm.org/D55719 llvm-svn: 349551
2018-12-19 06:18:41 +08:00
Data.MapTypeModifiers.push_back(TypeModifier);
Data.MapTypeModifiersLoc.push_back(Tok.getLocation());
[OpenMP 5.0] Parsing/sema support for map clause with mapper modifier. This patch implements the parsing and sema support for OpenMP map clauses with potential user-defined mapper attached. User defined mapper is a new feature in OpenMP 5.0. A map clause can have an explicit or implicit associated mapper, which instructs the compiler to generate extra data mapping. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target map(mapper(id) tofrom: ss) // use the mapper with name 'id' to map ss Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58074 llvm-svn: 354347
2019-02-20 00:38:20 +08:00
ConsumeToken();
} else if (TypeModifier == OMPC_MAP_MODIFIER_mapper) {
Data.MapTypeModifiers.push_back(TypeModifier);
Data.MapTypeModifiersLoc.push_back(Tok.getLocation());
ConsumeToken();
[OpenMP 5.0] Parsing/sema support for to clause with mapper modifier. This patch implements the parsing and sema support for OpenMP to clause with potential user-defined mappers attached. User defined mapper is a new feature in OpenMP 5.0. A to/from clause can have an explicit or implicit associated mapper, which instructs the compiler to generate and use customized mapping functions. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target update to(mapper(id): ss) // use the mapper with name 'id' to map ss to device Contributed-by: <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58523 llvm-svn: 354698
2019-02-23 06:29:42 +08:00
if (parseMapperModifier(Data))
[OpenMP 5.0] Parsing/sema support for map clause with mapper modifier. This patch implements the parsing and sema support for OpenMP map clauses with potential user-defined mapper attached. User defined mapper is a new feature in OpenMP 5.0. A map clause can have an explicit or implicit associated mapper, which instructs the compiler to generate extra data mapping. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target map(mapper(id) tofrom: ss) // use the mapper with name 'id' to map ss Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58074 llvm-svn: 354347
2019-02-20 00:38:20 +08:00
return true;
[OPENMP] parsing and sema support for 'close' map-type-modifier A map clause with the close map-type-modifier is a hint to prefer that the variables are mapped using a copy into faster memory. Patch by Ahsan Saghir (saghir) Differential Revision: https://reviews.llvm.org/D55719 llvm-svn: 349551
2018-12-19 06:18:41 +08:00
} else {
// For the case of unknown map-type-modifier or a map-type.
// Map-type is followed by a colon; the function returns when it
// encounters a token followed by a colon.
if (Tok.is(tok::comma)) {
[OpenMP 5.0] Parsing/sema support for map clause with mapper modifier. This patch implements the parsing and sema support for OpenMP map clauses with potential user-defined mapper attached. User defined mapper is a new feature in OpenMP 5.0. A map clause can have an explicit or implicit associated mapper, which instructs the compiler to generate extra data mapping. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target map(mapper(id) tofrom: ss) // use the mapper with name 'id' to map ss Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58074 llvm-svn: 354347
2019-02-20 00:38:20 +08:00
Diag(Tok, diag::err_omp_map_type_modifier_missing);
ConsumeToken();
[OPENMP] parsing and sema support for 'close' map-type-modifier A map clause with the close map-type-modifier is a hint to prefer that the variables are mapped using a copy into faster memory. Patch by Ahsan Saghir (saghir) Differential Revision: https://reviews.llvm.org/D55719 llvm-svn: 349551
2018-12-19 06:18:41 +08:00
continue;
}
// Potential map-type token as it is followed by a colon.
if (PP.LookAhead(0).is(tok::colon))
[OpenMP 5.0] Parsing/sema support for map clause with mapper modifier. This patch implements the parsing and sema support for OpenMP map clauses with potential user-defined mapper attached. User defined mapper is a new feature in OpenMP 5.0. A map clause can have an explicit or implicit associated mapper, which instructs the compiler to generate extra data mapping. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target map(mapper(id) tofrom: ss) // use the mapper with name 'id' to map ss Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58074 llvm-svn: 354347
2019-02-20 00:38:20 +08:00
return false;
[OpenMP] Implement TR8 `present` map type modifier in Clang (1/2) This patch implements Clang front end support for the OpenMP TR8 `present` map type modifier. The next patch in this series implements OpenMP runtime support. This patch does not attempt to implement TR8 sec. 2.22.7.1 "map Clause", p. 319, L14-16: > If a map clause with a present map-type-modifier is present in a map > clause, then the effect of the clause is ordered before all other > map clauses that do not have the present modifier. Compare to L10-11, which Clang does not appear to implement yet: > For a given construct, the effect of a map clause with the to, from, > or tofrom map-type is ordered before the effect of a map clause with > the alloc, release, or delete map-type. This patch also does not implement the `present` implicit-behavior for `defaultmap` or the `present` motion-modifier for `target update`. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D83061
2020-07-22 22:14:00 +08:00
Diag(Tok, diag::err_omp_unknown_map_type_modifier)
[OpenMP][OpenACC] Implement `ompx_hold` map type modifier extension in Clang (1/2) This patch implements Clang support for an original OpenMP extension we have developed to support OpenACC: the `ompx_hold` map type modifier. The next patch in this series, D106510, implements OpenMP runtime support. Consider the following example: ``` #pragma omp target data map(ompx_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 `ompx_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. (As usual, the standard OpenMP reference count for `x` must also reach zero before the data is unmapped.) Justification for inclusion in Clang and LLVM's OpenMP runtime: * The `ompx_hold` modifier supports OpenACC functionality (structured reference count) that cannot be achieved in standard OpenMP, as of 5.1. * The runtime implementation for `ompx_hold` (next patch) will thus be used by Flang's OpenACC support. * The Clang implementation for `ompx_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 `ompx_hold` is also used by the tests in the runtime implementation. That syntactic support makes the tests more readable than low-level runtime calls can. Moreover, upstream Flang and Clang do not yet support OpenACC syntax sufficiently for writing the tests. * More generally, the Clang implementation enables a clean separation of concerns between OpenACC and OpenMP development in LLVM. That is, LLVM's OpenMP developers can discuss, modify, and debug LLVM's extended OpenMP implementation and test suite without directly considering OpenACC's language and execution model, which can be handled by LLVM's OpenACC developers. * OpenMP users might find the `ompx_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. For example, it explains how the runtime must support two reference counts, as specified by OpenACC. Clang recognizes `ompx_hold` unless `-fno-openmp-extensions`, a new command-line option introduced by this patch, is specified. Reviewed By: ABataev, jdoerfert, protze.joachim, grokos Differential Revision: https://reviews.llvm.org/D106509
2021-09-01 03:17:07 +08:00
<< (getLangOpts().OpenMP >= 51 ? 1 : 0)
<< getLangOpts().OpenMPExtensions;
[OpenMP 5.0] Parsing/sema support for map clause with mapper modifier. This patch implements the parsing and sema support for OpenMP map clauses with potential user-defined mapper attached. User defined mapper is a new feature in OpenMP 5.0. A map clause can have an explicit or implicit associated mapper, which instructs the compiler to generate extra data mapping. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target map(mapper(id) tofrom: ss) // use the mapper with name 'id' to map ss Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58074 llvm-svn: 354347
2019-02-20 00:38:20 +08:00
ConsumeToken();
[OPENMP] parsing and sema support for 'close' map-type-modifier A map clause with the close map-type-modifier is a hint to prefer that the variables are mapped using a copy into faster memory. Patch by Ahsan Saghir (saghir) Differential Revision: https://reviews.llvm.org/D55719 llvm-svn: 349551
2018-12-19 06:18:41 +08:00
}
[OpenMP 5.0] Parsing/sema support for map clause with mapper modifier. This patch implements the parsing and sema support for OpenMP map clauses with potential user-defined mapper attached. User defined mapper is a new feature in OpenMP 5.0. A map clause can have an explicit or implicit associated mapper, which instructs the compiler to generate extra data mapping. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target map(mapper(id) tofrom: ss) // use the mapper with name 'id' to map ss Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58074 llvm-svn: 354347
2019-02-20 00:38:20 +08:00
if (getCurToken().is(tok::comma))
ConsumeToken();
[OPENMP] parsing and sema support for 'close' map-type-modifier A map clause with the close map-type-modifier is a hint to prefer that the variables are mapped using a copy into faster memory. Patch by Ahsan Saghir (saghir) Differential Revision: https://reviews.llvm.org/D55719 llvm-svn: 349551
2018-12-19 06:18:41 +08:00
}
[OpenMP 5.0] Parsing/sema support for map clause with mapper modifier. This patch implements the parsing and sema support for OpenMP map clauses with potential user-defined mapper attached. User defined mapper is a new feature in OpenMP 5.0. A map clause can have an explicit or implicit associated mapper, which instructs the compiler to generate extra data mapping. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target map(mapper(id) tofrom: ss) // use the mapper with name 'id' to map ss Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58074 llvm-svn: 354347
2019-02-20 00:38:20 +08:00
return false;
[OPENMP] parsing and sema support for 'close' map-type-modifier A map clause with the close map-type-modifier is a hint to prefer that the variables are mapped using a copy into faster memory. Patch by Ahsan Saghir (saghir) Differential Revision: https://reviews.llvm.org/D55719 llvm-svn: 349551
2018-12-19 06:18:41 +08:00
}
/// Checks if the token is a valid map-type.
[OpenMP] Implement TR8 `present` map type modifier in Clang (1/2) This patch implements Clang front end support for the OpenMP TR8 `present` map type modifier. The next patch in this series implements OpenMP runtime support. This patch does not attempt to implement TR8 sec. 2.22.7.1 "map Clause", p. 319, L14-16: > If a map clause with a present map-type-modifier is present in a map > clause, then the effect of the clause is ordered before all other > map clauses that do not have the present modifier. Compare to L10-11, which Clang does not appear to implement yet: > For a given construct, the effect of a map clause with the to, from, > or tofrom map-type is ordered before the effect of a map clause with > the alloc, release, or delete map-type. This patch also does not implement the `present` implicit-behavior for `defaultmap` or the `present` motion-modifier for `target update`. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D83061
2020-07-22 22:14:00 +08:00
/// FIXME: It will return an OpenMPMapModifierKind if that's what it parses.
[OPENMP] parsing and sema support for 'close' map-type-modifier A map clause with the close map-type-modifier is a hint to prefer that the variables are mapped using a copy into faster memory. Patch by Ahsan Saghir (saghir) Differential Revision: https://reviews.llvm.org/D55719 llvm-svn: 349551
2018-12-19 06:18:41 +08:00
static OpenMPMapClauseKind isMapType(Parser &P) {
Token Tok = P.getCurToken();
// The map-type token can be either an identifier or the C++ delete keyword.
if (!Tok.isOneOf(tok::identifier, tok::kw_delete))
return OMPC_MAP_unknown;
Preprocessor &PP = P.getPreprocessor();
[OpenMP] Implement TR8 `present` map type modifier in Clang (1/2) This patch implements Clang front end support for the OpenMP TR8 `present` map type modifier. The next patch in this series implements OpenMP runtime support. This patch does not attempt to implement TR8 sec. 2.22.7.1 "map Clause", p. 319, L14-16: > If a map clause with a present map-type-modifier is present in a map > clause, then the effect of the clause is ordered before all other > map clauses that do not have the present modifier. Compare to L10-11, which Clang does not appear to implement yet: > For a given construct, the effect of a map clause with the to, from, > or tofrom map-type is ordered before the effect of a map clause with > the alloc, release, or delete map-type. This patch also does not implement the `present` implicit-behavior for `defaultmap` or the `present` motion-modifier for `target update`. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D83061
2020-07-22 22:14:00 +08:00
OpenMPMapClauseKind MapType =
static_cast<OpenMPMapClauseKind>(getOpenMPSimpleClauseType(
[OpenMP][OpenACC] Implement `ompx_hold` map type modifier extension in Clang (1/2) This patch implements Clang support for an original OpenMP extension we have developed to support OpenACC: the `ompx_hold` map type modifier. The next patch in this series, D106510, implements OpenMP runtime support. Consider the following example: ``` #pragma omp target data map(ompx_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 `ompx_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. (As usual, the standard OpenMP reference count for `x` must also reach zero before the data is unmapped.) Justification for inclusion in Clang and LLVM's OpenMP runtime: * The `ompx_hold` modifier supports OpenACC functionality (structured reference count) that cannot be achieved in standard OpenMP, as of 5.1. * The runtime implementation for `ompx_hold` (next patch) will thus be used by Flang's OpenACC support. * The Clang implementation for `ompx_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 `ompx_hold` is also used by the tests in the runtime implementation. That syntactic support makes the tests more readable than low-level runtime calls can. Moreover, upstream Flang and Clang do not yet support OpenACC syntax sufficiently for writing the tests. * More generally, the Clang implementation enables a clean separation of concerns between OpenACC and OpenMP development in LLVM. That is, LLVM's OpenMP developers can discuss, modify, and debug LLVM's extended OpenMP implementation and test suite without directly considering OpenACC's language and execution model, which can be handled by LLVM's OpenACC developers. * OpenMP users might find the `ompx_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. For example, it explains how the runtime must support two reference counts, as specified by OpenACC. Clang recognizes `ompx_hold` unless `-fno-openmp-extensions`, a new command-line option introduced by this patch, is specified. Reviewed By: ABataev, jdoerfert, protze.joachim, grokos Differential Revision: https://reviews.llvm.org/D106509
2021-09-01 03:17:07 +08:00
OMPC_map, PP.getSpelling(Tok), P.getLangOpts()));
[OPENMP] parsing and sema support for 'close' map-type-modifier A map clause with the close map-type-modifier is a hint to prefer that the variables are mapped using a copy into faster memory. Patch by Ahsan Saghir (saghir) Differential Revision: https://reviews.llvm.org/D55719 llvm-svn: 349551
2018-12-19 06:18:41 +08:00
return MapType;
}
/// Parse map-type in map clause.
/// map([ [map-type-modifier[,] [map-type-modifier[,] ...] map-type : ] list)
[CodeComplete] Propagate preferred type for function arguments in more cases Summary: See the added test for some new cases. This change also removes special code completion calls inside the ParseExpressionList function now that we properly propagate expected type to the function responsible for parsing elements of the expression list (ParseAssignmentExpression). Reviewers: kadircet Reviewed By: kadircet Subscribers: xbolva00, jdoerfert, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58541 llvm-svn: 354864
2019-02-26 19:01:50 +08:00
/// where, map-type ::= to | from | tofrom | alloc | release | delete
[OPENMP] parsing and sema support for 'close' map-type-modifier A map clause with the close map-type-modifier is a hint to prefer that the variables are mapped using a copy into faster memory. Patch by Ahsan Saghir (saghir) Differential Revision: https://reviews.llvm.org/D55719 llvm-svn: 349551
2018-12-19 06:18:41 +08:00
static void parseMapType(Parser &P, Parser::OpenMPVarListDataTy &Data) {
Token Tok = P.getCurToken();
if (Tok.is(tok::colon)) {
P.Diag(Tok, diag::err_omp_map_type_missing);
return;
}
[OPENMP50]Basic support for conditional lastprivate. Added parsing/sema checks for conditional lastprivates.
2019-12-21 00:04:57 +08:00
Data.ExtraModifier = isMapType(P);
if (Data.ExtraModifier == OMPC_MAP_unknown)
[OPENMP] parsing and sema support for 'close' map-type-modifier A map clause with the close map-type-modifier is a hint to prefer that the variables are mapped using a copy into faster memory. Patch by Ahsan Saghir (saghir) Differential Revision: https://reviews.llvm.org/D55719 llvm-svn: 349551
2018-12-19 06:18:41 +08:00
P.Diag(Tok, diag::err_omp_unknown_map_type);
P.ConsumeToken();
}
[OPENMP50]Add initial support for OpenMP 5.0 iterator. Added basic parsing/semantic analysis/(de)serialization support for iterator expression introduced in OpenMP 5.0.
2020-04-02 03:06:38 +08:00
/// Parses simple expression in parens for single-expression clauses of OpenMP
/// constructs.
ExprResult Parser::ParseOpenMPIteratorsExpr() {
assert(Tok.is(tok::identifier) && PP.getSpelling(Tok) == "iterator" &&
"Expected 'iterator' token.");
SourceLocation IteratorKwLoc = ConsumeToken();
BalancedDelimiterTracker T(*this, tok::l_paren, tok::annot_pragma_openmp_end);
if (T.expectAndConsume(diag::err_expected_lparen_after, "iterator"))
return ExprError();
SourceLocation LLoc = T.getOpenLocation();
SmallVector<Sema::OMPIteratorData, 4> Data;
while (Tok.isNot(tok::r_paren) && Tok.isNot(tok::annot_pragma_openmp_end)) {
// Check if the type parsing is required.
ParsedType IteratorType;
if (Tok.isNot(tok::identifier) || NextToken().isNot(tok::equal)) {
// identifier '=' is not found - parse type.
TypeResult TR = ParseTypeName();
if (TR.isInvalid()) {
T.skipToEnd();
return ExprError();
}
IteratorType = TR.get();
}
// Parse identifier.
IdentifierInfo *II = nullptr;
SourceLocation IdLoc;
if (Tok.is(tok::identifier)) {
II = Tok.getIdentifierInfo();
IdLoc = ConsumeToken();
} else {
Diag(Tok, diag::err_expected_unqualified_id) << 0;
}
// Parse '='.
SourceLocation AssignLoc;
if (Tok.is(tok::equal))
AssignLoc = ConsumeToken();
else
Diag(Tok, diag::err_omp_expected_equal_in_iterator);
// Parse range-specification - <begin> ':' <end> [ ':' <step> ]
ColonProtectionRAIIObject ColonRAII(*this);
// Parse <begin>
SourceLocation Loc = Tok.getLocation();
ExprResult LHS = ParseCastExpression(AnyCastExpr);
ExprResult Begin = Actions.CorrectDelayedTyposInExpr(
ParseRHSOfBinaryExpression(LHS, prec::Conditional));
Begin = Actions.ActOnFinishFullExpr(Begin.get(), Loc,
/*DiscardedValue=*/false);
// Parse ':'.
SourceLocation ColonLoc;
if (Tok.is(tok::colon))
ColonLoc = ConsumeToken();
// Parse <end>
Loc = Tok.getLocation();
LHS = ParseCastExpression(AnyCastExpr);
ExprResult End = Actions.CorrectDelayedTyposInExpr(
ParseRHSOfBinaryExpression(LHS, prec::Conditional));
End = Actions.ActOnFinishFullExpr(End.get(), Loc,
/*DiscardedValue=*/false);
SourceLocation SecColonLoc;
ExprResult Step;
// Parse optional step.
if (Tok.is(tok::colon)) {
// Parse ':'
SecColonLoc = ConsumeToken();
// Parse <step>
Loc = Tok.getLocation();
LHS = ParseCastExpression(AnyCastExpr);
Step = Actions.CorrectDelayedTyposInExpr(
ParseRHSOfBinaryExpression(LHS, prec::Conditional));
Step = Actions.ActOnFinishFullExpr(Step.get(), Loc,
/*DiscardedValue=*/false);
}
// Parse ',' or ')'
if (Tok.isNot(tok::comma) && Tok.isNot(tok::r_paren))
Diag(Tok, diag::err_omp_expected_punc_after_iterator);
if (Tok.is(tok::comma))
ConsumeToken();
Sema::OMPIteratorData &D = Data.emplace_back();
D.DeclIdent = II;
D.DeclIdentLoc = IdLoc;
D.Type = IteratorType;
D.AssignLoc = AssignLoc;
D.ColonLoc = ColonLoc;
D.SecColonLoc = SecColonLoc;
D.Range.Begin = Begin.get();
D.Range.End = End.get();
D.Range.Step = Step.get();
}
// Parse ')'.
SourceLocation RLoc = Tok.getLocation();
if (!T.consumeClose())
RLoc = T.getCloseLocation();
return Actions.ActOnOMPIteratorExpr(getCurScope(), IteratorKwLoc, LLoc, RLoc,
Data);
}
[OPENMP 4.0] Support for 'uniform' clause in 'declare simd' directive. OpenMP 4.0 defines clause 'uniform' in 'declare simd' directive: 'uniform' '(' <argument-list> ')' The uniform clause declares one or more arguments to have an invariant value for all concurrent invocations of the function in the execution of a single SIMD loop. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266041
2016-04-12 13:28:34 +08:00
/// Parses clauses with list.
bool Parser::ParseOpenMPVarList(OpenMPDirectiveKind DKind,
OpenMPClauseKind Kind,
SmallVectorImpl<Expr *> &Vars,
OpenMPVarListDataTy &Data) {
UnqualifiedId UnqualifiedReductionId;
[OPENMP] Initial support of 'reduction' clause llvm-svn: 211007
2014-06-16 15:08:35 +08:00
bool InvalidReductionId = false;
[OpenMP 5.0] Parsing/sema support for to clause with mapper modifier. This patch implements the parsing and sema support for OpenMP to clause with potential user-defined mappers attached. User defined mapper is a new feature in OpenMP 5.0. A to/from clause can have an explicit or implicit associated mapper, which instructs the compiler to generate and use customized mapping functions. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target update to(mapper(id): ss) // use the mapper with name 'id' to map ss to device Contributed-by: <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58523 llvm-svn: 354698
2019-02-23 06:29:42 +08:00
bool IsInvalidMapperModifier = false;
[OPENMP] Initial support for 'depend' clause (4.0). Parsing and sema analysis (without support for array sections in arguments) for 'depend' clause (used in 'task' directive, OpenMP 4.0). llvm-svn: 240409
2015-06-23 22:25:19 +08:00
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
// Parse '('.
Revert "[OPENMP] Fix for parsing OpenMP directives with extra braces, brackets and parens" These parser changes were redundant. The same or better recovery can be achieved with a one-line fix to SkipUntil() due to land in the next commit. This reverts commit r197553. llvm-svn: 197597
2013-12-19 03:10:49 +08:00
BalancedDelimiterTracker T(*this, tok::l_paren, tok::annot_pragma_openmp_end);
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
if (T.expectAndConsume(diag::err_expected_lparen_after,
[OpenMP][NFCI] Move OpenMP clause information to `lib/Frontend/OpenMP` This is a cleanup and normalization patch that also enables reuse with Flang later on. A follow up will clean up and move the directive -> clauses mapping. Reviewed By: fghanim Differential Revision: https://reviews.llvm.org/D77112
2020-03-31 08:58:40 +08:00
getOpenMPClauseName(Kind).data()))
[OPENMP 4.0] Support for 'uniform' clause in 'declare simd' directive. OpenMP 4.0 defines clause 'uniform' in 'declare simd' directive: 'uniform' '(' <argument-list> ')' The uniform clause declares one or more arguments to have an invariant value for all concurrent invocations of the function in the execution of a single SIMD loop. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266041
2016-04-12 13:28:34 +08:00
return true;
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
[OPENMP50]Add initial support for 'affinity' clause. Summary: Added parsing/sema/serialization support for affinity clause in task directives. Reviewers: jdoerfert Subscribers: yaxunl, guansong, arphaman, llvm-commits, cfe-commits, caomhin Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D80148
2020-05-19 01:37:53 +08:00
bool HasIterator = false;
[OPENMP 4.1] Initial support for modifiers in 'linear' clause. OpenMP 4.1 adds 3 optional modifiers to 'linear' clause. Format of 'linear' clause has changed to: ``` linear(linear-list[ : linear-step]) ``` where linear-list is one of the following ``` list modifier(list) ``` where modifier is one of the following: ``` ref (C++) val (C/C++) uval (C++) ``` Patch adds parsing and sema analysis for these modifiers. llvm-svn: 245550
2015-08-20 18:54:39 +08:00
bool NeedRParenForLinear = false;
BalancedDelimiterTracker LinearT(*this, tok::l_paren,
[OpenMP][NFC] Clang format ParseOpenMP ParseOpenMP.cpp was pretty much clang-formatted except a few minor locations. Let's make it a clang formatted file. Reviewed By: JonChesterfield Differential Revision: https://reviews.llvm.org/D90440
2020-10-30 07:44:28 +08:00
tok::annot_pragma_openmp_end);
[OPENMP] Initial support of 'reduction' clause llvm-svn: 211007
2014-06-16 15:08:35 +08:00
// Handle reduction-identifier for reduction clause.
[OPENMP] Initial support for 'in_reduction' clause. Parsing/sema analysis for 'in_reduction' clause for task-based directives. llvm-svn: 308768
2017-07-22 02:48:21 +08:00
if (Kind == OMPC_reduction || Kind == OMPC_task_reduction ||
Kind == OMPC_in_reduction) {
[OPENMP50]Add 'default' modifier in reduction clauses. Added full support for 'default' modifier in the reduction clauses.
2020-03-24 05:30:38 +08:00
Data.ExtraModifier = OMPC_REDUCTION_unknown;
if (Kind == OMPC_reduction && getLangOpts().OpenMP >= 50 &&
(Tok.is(tok::identifier) || Tok.is(tok::kw_default)) &&
NextToken().is(tok::comma)) {
// Parse optional reduction modifier.
[OpenMP][OpenACC] Implement `ompx_hold` map type modifier extension in Clang (1/2) This patch implements Clang support for an original OpenMP extension we have developed to support OpenACC: the `ompx_hold` map type modifier. The next patch in this series, D106510, implements OpenMP runtime support. Consider the following example: ``` #pragma omp target data map(ompx_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 `ompx_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. (As usual, the standard OpenMP reference count for `x` must also reach zero before the data is unmapped.) Justification for inclusion in Clang and LLVM's OpenMP runtime: * The `ompx_hold` modifier supports OpenACC functionality (structured reference count) that cannot be achieved in standard OpenMP, as of 5.1. * The runtime implementation for `ompx_hold` (next patch) will thus be used by Flang's OpenACC support. * The Clang implementation for `ompx_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 `ompx_hold` is also used by the tests in the runtime implementation. That syntactic support makes the tests more readable than low-level runtime calls can. Moreover, upstream Flang and Clang do not yet support OpenACC syntax sufficiently for writing the tests. * More generally, the Clang implementation enables a clean separation of concerns between OpenACC and OpenMP development in LLVM. That is, LLVM's OpenMP developers can discuss, modify, and debug LLVM's extended OpenMP implementation and test suite without directly considering OpenACC's language and execution model, which can be handled by LLVM's OpenACC developers. * OpenMP users might find the `ompx_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. For example, it explains how the runtime must support two reference counts, as specified by OpenACC. Clang recognizes `ompx_hold` unless `-fno-openmp-extensions`, a new command-line option introduced by this patch, is specified. Reviewed By: ABataev, jdoerfert, protze.joachim, grokos Differential Revision: https://reviews.llvm.org/D106509
2021-09-01 03:17:07 +08:00
Data.ExtraModifier =
getOpenMPSimpleClauseType(Kind, PP.getSpelling(Tok), getLangOpts());
[OPENMP50]Add 'default' modifier in reduction clauses. Added full support for 'default' modifier in the reduction clauses.
2020-03-24 05:30:38 +08:00
Data.ExtraModifierLoc = Tok.getLocation();
ConsumeToken();
assert(Tok.is(tok::comma) && "Expected comma.");
(void)ConsumeToken();
}
[OPENMP] Initial support of 'reduction' clause llvm-svn: 211007
2014-06-16 15:08:35 +08:00
ColonProtectionRAIIObject ColonRAII(*this);
[OPENMP 4.0] Use 'declare reduction' constructs in 'reduction' clauses. OpenMP 4.0 allows to define custom reduction operations using '#pragma omp declare reduction' construct. Patch allows to use this custom defined reduction operations in 'reduction' clauses. llvm-svn: 263701
2016-03-17 18:19:46 +08:00
if (getLangOpts().CPlusPlus)
[OpenMP 5.0] Parsing/sema support for map clause with mapper modifier. This patch implements the parsing and sema support for OpenMP map clauses with potential user-defined mapper attached. User defined mapper is a new feature in OpenMP 5.0. A map clause can have an explicit or implicit associated mapper, which instructs the compiler to generate extra data mapping. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target map(mapper(id) tofrom: ss) // use the mapper with name 'id' to map ss Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58074 llvm-svn: 354347
2019-02-20 00:38:20 +08:00
ParseOptionalCXXScopeSpecifier(Data.ReductionOrMapperIdScopeSpec,
[OPENMP 4.0] Use 'declare reduction' constructs in 'reduction' clauses. OpenMP 4.0 allows to define custom reduction operations using '#pragma omp declare reduction' construct. Patch allows to use this custom defined reduction operations in 'reduction' clauses. llvm-svn: 263701
2016-03-17 18:19:46 +08:00
/*ObjectType=*/nullptr,
[Parser] Avoid spurious 'missing template' error in presence of typos. Suppress those diagnostics if lhs of a member expression contains errors. Typo correction produces dependent expressions even in non-template code, that led to spurious diagnostics before. previous: /tmp/t.cpp:6:17: error: use 'template' keyword to treat 'f' as a dependent template name auto a = bilder.f<int>(); ^ template /tmp/t.cpp:6:10: error: use of undeclared identifier 'bilder'; did you mean 'builder'? auto a = bilder.f<int>(); ^~~~~~ builder vs now: /tmp/t.cpp:6:10: error: use of undeclared identifier 'bilder'; did you mean 'builder'? auto a = bilder.f<int>(); ^~~~~~ builder Original patch from Ilya. Reviewers: sammccall Reviewed By: sammccall Tags: #clang Differential Revision: https://reviews.llvm.org/D65592
2020-03-19 16:12:29 +08:00
/*ObjectHadErrors=*/false,
[OPENMP 4.0] Use 'declare reduction' constructs in 'reduction' clauses. OpenMP 4.0 allows to define custom reduction operations using '#pragma omp declare reduction' construct. Patch allows to use this custom defined reduction operations in 'reduction' clauses. llvm-svn: 263701
2016-03-17 18:19:46 +08:00
/*EnteringContext=*/false);
[OpenMP 5.0] Parsing/sema support for map clause with mapper modifier. This patch implements the parsing and sema support for OpenMP map clauses with potential user-defined mapper attached. User defined mapper is a new feature in OpenMP 5.0. A map clause can have an explicit or implicit associated mapper, which instructs the compiler to generate extra data mapping. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target map(mapper(id) tofrom: ss) // use the mapper with name 'id' to map ss Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58074 llvm-svn: 354347
2019-02-20 00:38:20 +08:00
InvalidReductionId = ParseReductionId(
*this, Data.ReductionOrMapperIdScopeSpec, UnqualifiedReductionId);
[OPENMP] Initial support of 'reduction' clause llvm-svn: 211007
2014-06-16 15:08:35 +08:00
if (InvalidReductionId) {
SkipUntil(tok::colon, tok::r_paren, tok::annot_pragma_openmp_end,
StopBeforeMatch);
}
[OPENMP 4.0] Support for 'uniform' clause in 'declare simd' directive. OpenMP 4.0 defines clause 'uniform' in 'declare simd' directive: 'uniform' '(' <argument-list> ')' The uniform clause declares one or more arguments to have an invariant value for all concurrent invocations of the function in the execution of a single SIMD loop. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266041
2016-04-12 13:28:34 +08:00
if (Tok.is(tok::colon))
Data.ColonLoc = ConsumeToken();
else
[OPENMP] Initial support of 'reduction' clause llvm-svn: 211007
2014-06-16 15:08:35 +08:00
Diag(Tok, diag::warn_pragma_expected_colon) << "reduction identifier";
[OPENMP 4.0] Support for 'uniform' clause in 'declare simd' directive. OpenMP 4.0 defines clause 'uniform' in 'declare simd' directive: 'uniform' '(' <argument-list> ')' The uniform clause declares one or more arguments to have an invariant value for all concurrent invocations of the function in the execution of a single SIMD loop. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266041
2016-04-12 13:28:34 +08:00
if (!InvalidReductionId)
[OpenMP 5.0] Parsing/sema support for map clause with mapper modifier. This patch implements the parsing and sema support for OpenMP map clauses with potential user-defined mapper attached. User defined mapper is a new feature in OpenMP 5.0. A map clause can have an explicit or implicit associated mapper, which instructs the compiler to generate extra data mapping. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target map(mapper(id) tofrom: ss) // use the mapper with name 'id' to map ss Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58074 llvm-svn: 354347
2019-02-20 00:38:20 +08:00
Data.ReductionOrMapperId =
[OPENMP 4.0] Support for 'uniform' clause in 'declare simd' directive. OpenMP 4.0 defines clause 'uniform' in 'declare simd' directive: 'uniform' '(' <argument-list> ')' The uniform clause declares one or more arguments to have an invariant value for all concurrent invocations of the function in the execution of a single SIMD loop. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266041
2016-04-12 13:28:34 +08:00
Actions.GetNameFromUnqualifiedId(UnqualifiedReductionId);
[OPENMP] Initial support for 'depend' clause (4.0). Parsing and sema analysis (without support for array sections in arguments) for 'depend' clause (used in 'task' directive, OpenMP 4.0). llvm-svn: 240409
2015-06-23 22:25:19 +08:00
} else if (Kind == OMPC_depend) {
[OPENMP50]Add initial support for OpenMP 5.0 iterator. Added basic parsing/semantic analysis/(de)serialization support for iterator expression introduced in OpenMP 5.0.
2020-04-02 03:06:38 +08:00
if (getLangOpts().OpenMP >= 50) {
if (Tok.is(tok::identifier) && PP.getSpelling(Tok) == "iterator") {
// Handle optional dependence modifier.
// iterator(iterators-definition)
// where iterators-definition is iterator-specifier [,
// iterators-definition ]
// where iterator-specifier is [ iterator-type ] identifier =
// range-specification
[OPENMP50]Add initial support for 'affinity' clause. Summary: Added parsing/sema/serialization support for affinity clause in task directives. Reviewers: jdoerfert Subscribers: yaxunl, guansong, arphaman, llvm-commits, cfe-commits, caomhin Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D80148
2020-05-19 01:37:53 +08:00
HasIterator = true;
[OPENMP50]Add initial support for OpenMP 5.0 iterator. Added basic parsing/semantic analysis/(de)serialization support for iterator expression introduced in OpenMP 5.0.
2020-04-02 03:06:38 +08:00
EnterScope(Scope::OpenMPDirectiveScope | Scope::DeclScope);
ExprResult IteratorRes = ParseOpenMPIteratorsExpr();
Data.DepModOrTailExpr = IteratorRes.get();
// Parse ','
ExpectAndConsume(tok::comma);
}
}
[OPENMP50]Basic support for conditional lastprivate. Added parsing/sema checks for conditional lastprivates.
2019-12-21 00:04:57 +08:00
// Handle dependency type for depend clause.
[OPENMP] Initial support for 'depend' clause (4.0). Parsing and sema analysis (without support for array sections in arguments) for 'depend' clause (used in 'task' directive, OpenMP 4.0). llvm-svn: 240409
2015-06-23 22:25:19 +08:00
ColonProtectionRAIIObject ColonRAII(*this);
[OPENMP50]Basic support for conditional lastprivate. Added parsing/sema checks for conditional lastprivates.
2019-12-21 00:04:57 +08:00
Data.ExtraModifier = getOpenMPSimpleClauseType(
[OpenMP] Implement TR8 `present` map type modifier in Clang (1/2) This patch implements Clang front end support for the OpenMP TR8 `present` map type modifier. The next patch in this series implements OpenMP runtime support. This patch does not attempt to implement TR8 sec. 2.22.7.1 "map Clause", p. 319, L14-16: > If a map clause with a present map-type-modifier is present in a map > clause, then the effect of the clause is ordered before all other > map clauses that do not have the present modifier. Compare to L10-11, which Clang does not appear to implement yet: > For a given construct, the effect of a map clause with the to, from, > or tofrom map-type is ordered before the effect of a map clause with > the alloc, release, or delete map-type. This patch also does not implement the `present` implicit-behavior for `defaultmap` or the `present` motion-modifier for `target update`. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D83061
2020-07-22 22:14:00 +08:00
Kind, Tok.is(tok::identifier) ? PP.getSpelling(Tok) : "",
[OpenMP][OpenACC] Implement `ompx_hold` map type modifier extension in Clang (1/2) This patch implements Clang support for an original OpenMP extension we have developed to support OpenACC: the `ompx_hold` map type modifier. The next patch in this series, D106510, implements OpenMP runtime support. Consider the following example: ``` #pragma omp target data map(ompx_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 `ompx_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. (As usual, the standard OpenMP reference count for `x` must also reach zero before the data is unmapped.) Justification for inclusion in Clang and LLVM's OpenMP runtime: * The `ompx_hold` modifier supports OpenACC functionality (structured reference count) that cannot be achieved in standard OpenMP, as of 5.1. * The runtime implementation for `ompx_hold` (next patch) will thus be used by Flang's OpenACC support. * The Clang implementation for `ompx_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 `ompx_hold` is also used by the tests in the runtime implementation. That syntactic support makes the tests more readable than low-level runtime calls can. Moreover, upstream Flang and Clang do not yet support OpenACC syntax sufficiently for writing the tests. * More generally, the Clang implementation enables a clean separation of concerns between OpenACC and OpenMP development in LLVM. That is, LLVM's OpenMP developers can discuss, modify, and debug LLVM's extended OpenMP implementation and test suite without directly considering OpenACC's language and execution model, which can be handled by LLVM's OpenACC developers. * OpenMP users might find the `ompx_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. For example, it explains how the runtime must support two reference counts, as specified by OpenACC. Clang recognizes `ompx_hold` unless `-fno-openmp-extensions`, a new command-line option introduced by this patch, is specified. Reviewed By: ABataev, jdoerfert, protze.joachim, grokos Differential Revision: https://reviews.llvm.org/D106509
2021-09-01 03:17:07 +08:00
getLangOpts());
[OPENMP50]Add 'default' modifier in reduction clauses. Added full support for 'default' modifier in the reduction clauses.
2020-03-24 05:30:38 +08:00
Data.ExtraModifierLoc = Tok.getLocation();
[OPENMP50]Basic support for conditional lastprivate. Added parsing/sema checks for conditional lastprivates.
2019-12-21 00:04:57 +08:00
if (Data.ExtraModifier == OMPC_DEPEND_unknown) {
[OPENMP] Initial support for 'depend' clause (4.0). Parsing and sema analysis (without support for array sections in arguments) for 'depend' clause (used in 'task' directive, OpenMP 4.0). llvm-svn: 240409
2015-06-23 22:25:19 +08:00
SkipUntil(tok::colon, tok::r_paren, tok::annot_pragma_openmp_end,
StopBeforeMatch);
} else {
ConsumeToken();
[OPENMP 4.5] Parsing/sema analysis for 'depend(source)' clause in 'ordered' directive. OpenMP 4.5 adds 'depend(source)' clause for 'ordered' directive to support cross-iteration dependence. Patch adds parsing and semantic analysis for this construct. llvm-svn: 255986
2015-12-18 13:05:56 +08:00
// Special processing for depend(source) clause.
[OPENMP50]Basic support for conditional lastprivate. Added parsing/sema checks for conditional lastprivates.
2019-12-21 00:04:57 +08:00
if (DKind == OMPD_ordered && Data.ExtraModifier == OMPC_DEPEND_source) {
[OPENMP 4.5] Parsing/sema analysis for 'depend(source)' clause in 'ordered' directive. OpenMP 4.5 adds 'depend(source)' clause for 'ordered' directive to support cross-iteration dependence. Patch adds parsing and semantic analysis for this construct. llvm-svn: 255986
2015-12-18 13:05:56 +08:00
// Parse ')'.
T.consumeClose();
[OPENMP 4.0] Support for 'uniform' clause in 'declare simd' directive. OpenMP 4.0 defines clause 'uniform' in 'declare simd' directive: 'uniform' '(' <argument-list> ')' The uniform clause declares one or more arguments to have an invariant value for all concurrent invocations of the function in the execution of a single SIMD loop. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266041
2016-04-12 13:28:34 +08:00
return false;
[OPENMP 4.5] Parsing/sema analysis for 'depend(source)' clause in 'ordered' directive. OpenMP 4.5 adds 'depend(source)' clause for 'ordered' directive to support cross-iteration dependence. Patch adds parsing and semantic analysis for this construct. llvm-svn: 255986
2015-12-18 13:05:56 +08:00
}
[OPENMP] Initial support for 'depend' clause (4.0). Parsing and sema analysis (without support for array sections in arguments) for 'depend' clause (used in 'task' directive, OpenMP 4.0). llvm-svn: 240409
2015-06-23 22:25:19 +08:00
}
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-24 03:53:05 +08:00
if (Tok.is(tok::colon)) {
[OPENMP 4.0] Support for 'uniform' clause in 'declare simd' directive. OpenMP 4.0 defines clause 'uniform' in 'declare simd' directive: 'uniform' '(' <argument-list> ')' The uniform clause declares one or more arguments to have an invariant value for all concurrent invocations of the function in the execution of a single SIMD loop. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266041
2016-04-12 13:28:34 +08:00
Data.ColonLoc = ConsumeToken();
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-24 03:53:05 +08:00
} else {
[OPENMP 4.5] Parsing/sema analysis for 'depend(source)' clause in 'ordered' directive. OpenMP 4.5 adds 'depend(source)' clause for 'ordered' directive to support cross-iteration dependence. Patch adds parsing and semantic analysis for this construct. llvm-svn: 255986
2015-12-18 13:05:56 +08:00
Diag(Tok, DKind == OMPD_ordered ? diag::warn_pragma_expected_colon_r_paren
: diag::warn_pragma_expected_colon)
<< "dependency type";
[OPENMP] Initial support for 'depend' clause (4.0). Parsing and sema analysis (without support for array sections in arguments) for 'depend' clause (used in 'task' directive, OpenMP 4.0). llvm-svn: 240409
2015-06-23 22:25:19 +08:00
}
[OPENMP 4.1] Initial support for modifiers in 'linear' clause. OpenMP 4.1 adds 3 optional modifiers to 'linear' clause. Format of 'linear' clause has changed to: ``` linear(linear-list[ : linear-step]) ``` where linear-list is one of the following ``` list modifier(list) ``` where modifier is one of the following: ``` ref (C++) val (C/C++) uval (C++) ``` Patch adds parsing and sema analysis for these modifiers. llvm-svn: 245550
2015-08-20 18:54:39 +08:00
} else if (Kind == OMPC_linear) {
// Try to parse modifier if any.
[OPENMP50]Basic support for conditional lastprivate. Added parsing/sema checks for conditional lastprivates.
2019-12-21 00:04:57 +08:00
Data.ExtraModifier = OMPC_LINEAR_val;
[OPENMP 4.1] Initial support for modifiers in 'linear' clause. OpenMP 4.1 adds 3 optional modifiers to 'linear' clause. Format of 'linear' clause has changed to: ``` linear(linear-list[ : linear-step]) ``` where linear-list is one of the following ``` list modifier(list) ``` where modifier is one of the following: ``` ref (C++) val (C/C++) uval (C++) ``` Patch adds parsing and sema analysis for these modifiers. llvm-svn: 245550
2015-08-20 18:54:39 +08:00
if (Tok.is(tok::identifier) && PP.LookAhead(0).is(tok::l_paren)) {
[OpenMP][OpenACC] Implement `ompx_hold` map type modifier extension in Clang (1/2) This patch implements Clang support for an original OpenMP extension we have developed to support OpenACC: the `ompx_hold` map type modifier. The next patch in this series, D106510, implements OpenMP runtime support. Consider the following example: ``` #pragma omp target data map(ompx_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 `ompx_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. (As usual, the standard OpenMP reference count for `x` must also reach zero before the data is unmapped.) Justification for inclusion in Clang and LLVM's OpenMP runtime: * The `ompx_hold` modifier supports OpenACC functionality (structured reference count) that cannot be achieved in standard OpenMP, as of 5.1. * The runtime implementation for `ompx_hold` (next patch) will thus be used by Flang's OpenACC support. * The Clang implementation for `ompx_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 `ompx_hold` is also used by the tests in the runtime implementation. That syntactic support makes the tests more readable than low-level runtime calls can. Moreover, upstream Flang and Clang do not yet support OpenACC syntax sufficiently for writing the tests. * More generally, the Clang implementation enables a clean separation of concerns between OpenACC and OpenMP development in LLVM. That is, LLVM's OpenMP developers can discuss, modify, and debug LLVM's extended OpenMP implementation and test suite without directly considering OpenACC's language and execution model, which can be handled by LLVM's OpenACC developers. * OpenMP users might find the `ompx_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. For example, it explains how the runtime must support two reference counts, as specified by OpenACC. Clang recognizes `ompx_hold` unless `-fno-openmp-extensions`, a new command-line option introduced by this patch, is specified. Reviewed By: ABataev, jdoerfert, protze.joachim, grokos Differential Revision: https://reviews.llvm.org/D106509
2021-09-01 03:17:07 +08:00
Data.ExtraModifier =
getOpenMPSimpleClauseType(Kind, PP.getSpelling(Tok), getLangOpts());
[OPENMP50]Add 'default' modifier in reduction clauses. Added full support for 'default' modifier in the reduction clauses.
2020-03-24 05:30:38 +08:00
Data.ExtraModifierLoc = ConsumeToken();
[OPENMP 4.1] Initial support for modifiers in 'linear' clause. OpenMP 4.1 adds 3 optional modifiers to 'linear' clause. Format of 'linear' clause has changed to: ``` linear(linear-list[ : linear-step]) ``` where linear-list is one of the following ``` list modifier(list) ``` where modifier is one of the following: ``` ref (C++) val (C/C++) uval (C++) ``` Patch adds parsing and sema analysis for these modifiers. llvm-svn: 245550
2015-08-20 18:54:39 +08:00
LinearT.consumeOpen();
NeedRParenForLinear = true;
}
[OPENMP50]Basic support for conditional lastprivate. Added parsing/sema checks for conditional lastprivates.
2019-12-21 00:04:57 +08:00
} else if (Kind == OMPC_lastprivate) {
// Try to parse modifier if any.
Data.ExtraModifier = OMPC_LASTPRIVATE_unknown;
// Conditional modifier allowed only in OpenMP 5.0 and not supported in
// distribute and taskloop based directives.
if ((getLangOpts().OpenMP >= 50 && !isOpenMPDistributeDirective(DKind) &&
!isOpenMPTaskLoopDirective(DKind)) &&
Tok.is(tok::identifier) && PP.LookAhead(0).is(tok::colon)) {
[OpenMP][OpenACC] Implement `ompx_hold` map type modifier extension in Clang (1/2) This patch implements Clang support for an original OpenMP extension we have developed to support OpenACC: the `ompx_hold` map type modifier. The next patch in this series, D106510, implements OpenMP runtime support. Consider the following example: ``` #pragma omp target data map(ompx_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 `ompx_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. (As usual, the standard OpenMP reference count for `x` must also reach zero before the data is unmapped.) Justification for inclusion in Clang and LLVM's OpenMP runtime: * The `ompx_hold` modifier supports OpenACC functionality (structured reference count) that cannot be achieved in standard OpenMP, as of 5.1. * The runtime implementation for `ompx_hold` (next patch) will thus be used by Flang's OpenACC support. * The Clang implementation for `ompx_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 `ompx_hold` is also used by the tests in the runtime implementation. That syntactic support makes the tests more readable than low-level runtime calls can. Moreover, upstream Flang and Clang do not yet support OpenACC syntax sufficiently for writing the tests. * More generally, the Clang implementation enables a clean separation of concerns between OpenACC and OpenMP development in LLVM. That is, LLVM's OpenMP developers can discuss, modify, and debug LLVM's extended OpenMP implementation and test suite without directly considering OpenACC's language and execution model, which can be handled by LLVM's OpenACC developers. * OpenMP users might find the `ompx_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. For example, it explains how the runtime must support two reference counts, as specified by OpenACC. Clang recognizes `ompx_hold` unless `-fno-openmp-extensions`, a new command-line option introduced by this patch, is specified. Reviewed By: ABataev, jdoerfert, protze.joachim, grokos Differential Revision: https://reviews.llvm.org/D106509
2021-09-01 03:17:07 +08:00
Data.ExtraModifier =
getOpenMPSimpleClauseType(Kind, PP.getSpelling(Tok), getLangOpts());
[OPENMP50]Add 'default' modifier in reduction clauses. Added full support for 'default' modifier in the reduction clauses.
2020-03-24 05:30:38 +08:00
Data.ExtraModifierLoc = Tok.getLocation();
ConsumeToken();
[OPENMP50]Basic support for conditional lastprivate. Added parsing/sema checks for conditional lastprivates.
2019-12-21 00:04:57 +08:00
assert(Tok.is(tok::colon) && "Expected colon.");
Data.ColonLoc = ConsumeToken();
}
[OpenMP] Parsing and sema support for map clause http://reviews.llvm.org/D14134 llvm-svn: 253849
2015-11-23 13:32:03 +08:00
} else if (Kind == OMPC_map) {
// Handle map type for map clause.
ColonProtectionRAIIObject ColonRAII(*this);
[OpenMP] Fix parsing of delete map clause modifier in C++ mode. Summary: The map modifier 'delete' is parser in c++ mode as a delete keyword, which requires special handling in the map clause parsing. Reviewers: hfinkel, carlo.bertolli, arpith-jacob, kkwli0, ABataev Subscribers: cfe-commits, fraggamuffin, caomhin Differential Revision: http://reviews.llvm.org/D17629 llvm-svn: 262094
2016-02-27 08:01:58 +08:00
// The first identifier may be a list item, a map-type or a
[OPENMP] parsing and sema support for 'close' map-type-modifier A map clause with the close map-type-modifier is a hint to prefer that the variables are mapped using a copy into faster memory. Patch by Ahsan Saghir (saghir) Differential Revision: https://reviews.llvm.org/D55719 llvm-svn: 349551
2018-12-19 06:18:41 +08:00
// map-type-modifier. The map-type can also be delete which has the same
[OpenMP] Fix parsing of delete map clause modifier in C++ mode. Summary: The map modifier 'delete' is parser in c++ mode as a delete keyword, which requires special handling in the map clause parsing. Reviewers: hfinkel, carlo.bertolli, arpith-jacob, kkwli0, ABataev Subscribers: cfe-commits, fraggamuffin, caomhin Differential Revision: http://reviews.llvm.org/D17629 llvm-svn: 262094
2016-02-27 08:01:58 +08:00
// spelling of the C++ delete keyword.
[OPENMP50]Basic support for conditional lastprivate. Added parsing/sema checks for conditional lastprivates.
2019-12-21 00:04:57 +08:00
Data.ExtraModifier = OMPC_MAP_unknown;
[OPENMP50]Add 'default' modifier in reduction clauses. Added full support for 'default' modifier in the reduction clauses.
2020-03-24 05:30:38 +08:00
Data.ExtraModifierLoc = Tok.getLocation();
[OpenMP] Parsing and sema support for map clause http://reviews.llvm.org/D14134 llvm-svn: 253849
2015-11-23 13:32:03 +08:00
[OPENMP] parsing and sema support for 'close' map-type-modifier A map clause with the close map-type-modifier is a hint to prefer that the variables are mapped using a copy into faster memory. Patch by Ahsan Saghir (saghir) Differential Revision: https://reviews.llvm.org/D55719 llvm-svn: 349551
2018-12-19 06:18:41 +08:00
// Check for presence of a colon in the map clause.
TentativeParsingAction TPA(*this);
bool ColonPresent = false;
if (SkipUntil(tok::colon, tok::r_paren, tok::annot_pragma_openmp_end,
[OpenMP][NFC] Clang format ParseOpenMP ParseOpenMP.cpp was pretty much clang-formatted except a few minor locations. Let's make it a clang formatted file. Reviewed By: JonChesterfield Differential Revision: https://reviews.llvm.org/D90440
2020-10-30 07:44:28 +08:00
StopBeforeMatch)) {
[OPENMP] parsing and sema support for 'close' map-type-modifier A map clause with the close map-type-modifier is a hint to prefer that the variables are mapped using a copy into faster memory. Patch by Ahsan Saghir (saghir) Differential Revision: https://reviews.llvm.org/D55719 llvm-svn: 349551
2018-12-19 06:18:41 +08:00
if (Tok.is(tok::colon))
ColonPresent = true;
}
TPA.Revert();
// Only parse map-type-modifier[s] and map-type if a colon is present in
// the map clause.
if (ColonPresent) {
[OpenMP 5.0] Parsing/sema support for to clause with mapper modifier. This patch implements the parsing and sema support for OpenMP to clause with potential user-defined mappers attached. User defined mapper is a new feature in OpenMP 5.0. A to/from clause can have an explicit or implicit associated mapper, which instructs the compiler to generate and use customized mapping functions. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target update to(mapper(id): ss) // use the mapper with name 'id' to map ss to device Contributed-by: <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58523 llvm-svn: 354698
2019-02-23 06:29:42 +08:00
IsInvalidMapperModifier = parseMapTypeModifiers(Data);
if (!IsInvalidMapperModifier)
[OpenMP 5.0] Parsing/sema support for map clause with mapper modifier. This patch implements the parsing and sema support for OpenMP map clauses with potential user-defined mapper attached. User defined mapper is a new feature in OpenMP 5.0. A map clause can have an explicit or implicit associated mapper, which instructs the compiler to generate extra data mapping. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target map(mapper(id) tofrom: ss) // use the mapper with name 'id' to map ss Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58074 llvm-svn: 354347
2019-02-20 00:38:20 +08:00
parseMapType(*this, Data);
[OpenMP 5.0] Parsing/sema support for to clause with mapper modifier. This patch implements the parsing and sema support for OpenMP to clause with potential user-defined mappers attached. User defined mapper is a new feature in OpenMP 5.0. A to/from clause can have an explicit or implicit associated mapper, which instructs the compiler to generate and use customized mapping functions. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target update to(mapper(id): ss) // use the mapper with name 'id' to map ss to device Contributed-by: <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58523 llvm-svn: 354698
2019-02-23 06:29:42 +08:00
else
SkipUntil(tok::colon, tok::annot_pragma_openmp_end, StopBeforeMatch);
[OPENMP] parsing and sema support for 'close' map-type-modifier A map clause with the close map-type-modifier is a hint to prefer that the variables are mapped using a copy into faster memory. Patch by Ahsan Saghir (saghir) Differential Revision: https://reviews.llvm.org/D55719 llvm-svn: 349551
2018-12-19 06:18:41 +08:00
}
[OPENMP50]Basic support for conditional lastprivate. Added parsing/sema checks for conditional lastprivates.
2019-12-21 00:04:57 +08:00
if (Data.ExtraModifier == OMPC_MAP_unknown) {
Data.ExtraModifier = OMPC_MAP_tofrom;
[OPENMP 4.0] Support for 'uniform' clause in 'declare simd' directive. OpenMP 4.0 defines clause 'uniform' in 'declare simd' directive: 'uniform' '(' <argument-list> ')' The uniform clause declares one or more arguments to have an invariant value for all concurrent invocations of the function in the execution of a single SIMD loop. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266041
2016-04-12 13:28:34 +08:00
Data.IsMapTypeImplicit = true;
[OpenMP] Parsing and sema support for map clause http://reviews.llvm.org/D14134 llvm-svn: 253849
2015-11-23 13:32:03 +08:00
}
[OPENMP 4.0] Support for 'uniform' clause in 'declare simd' directive. OpenMP 4.0 defines clause 'uniform' in 'declare simd' directive: 'uniform' '(' <argument-list> ')' The uniform clause declares one or more arguments to have an invariant value for all concurrent invocations of the function in the execution of a single SIMD loop. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266041
2016-04-12 13:28:34 +08:00
if (Tok.is(tok::colon))
Data.ColonLoc = ConsumeToken();
[OpenMP 5.0] Parsing/sema support for from clause with mapper modifier. This patch implements the parsing and sema support for the OpenMP 'from'-clause with potential user-defined mappers attached. User-defined mappers are a new feature in OpenMP 5.0. A 'from'-clause can have an explicit or implicit associated mapper, which instructs the compiler to generate and use customized mapping functions. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target update from(mapper(id): ss) // use the mapper with name 'id' to map ss from device Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58638 llvm-svn: 354817
2019-02-26 04:34:15 +08:00
} else if (Kind == OMPC_to || Kind == OMPC_from) {
[OpenMP] Implement TR8 `present` motion modifier in Clang (1/2) This patch implements Clang front end support for the OpenMP TR8 `present` motion modifier for `omp target update` directives. The next patch in this series implements OpenMP runtime support. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D84711
2020-07-30 00:18:45 +08:00
while (Tok.is(tok::identifier)) {
[OpenMP][OpenACC] Implement `ompx_hold` map type modifier extension in Clang (1/2) This patch implements Clang support for an original OpenMP extension we have developed to support OpenACC: the `ompx_hold` map type modifier. The next patch in this series, D106510, implements OpenMP runtime support. Consider the following example: ``` #pragma omp target data map(ompx_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 `ompx_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. (As usual, the standard OpenMP reference count for `x` must also reach zero before the data is unmapped.) Justification for inclusion in Clang and LLVM's OpenMP runtime: * The `ompx_hold` modifier supports OpenACC functionality (structured reference count) that cannot be achieved in standard OpenMP, as of 5.1. * The runtime implementation for `ompx_hold` (next patch) will thus be used by Flang's OpenACC support. * The Clang implementation for `ompx_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 `ompx_hold` is also used by the tests in the runtime implementation. That syntactic support makes the tests more readable than low-level runtime calls can. Moreover, upstream Flang and Clang do not yet support OpenACC syntax sufficiently for writing the tests. * More generally, the Clang implementation enables a clean separation of concerns between OpenACC and OpenMP development in LLVM. That is, LLVM's OpenMP developers can discuss, modify, and debug LLVM's extended OpenMP implementation and test suite without directly considering OpenACC's language and execution model, which can be handled by LLVM's OpenACC developers. * OpenMP users might find the `ompx_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. For example, it explains how the runtime must support two reference counts, as specified by OpenACC. Clang recognizes `ompx_hold` unless `-fno-openmp-extensions`, a new command-line option introduced by this patch, is specified. Reviewed By: ABataev, jdoerfert, protze.joachim, grokos Differential Revision: https://reviews.llvm.org/D106509
2021-09-01 03:17:07 +08:00
auto Modifier = static_cast<OpenMPMotionModifierKind>(
getOpenMPSimpleClauseType(Kind, PP.getSpelling(Tok), getLangOpts()));
[OpenMP] Implement TR8 `present` motion modifier in Clang (1/2) This patch implements Clang front end support for the OpenMP TR8 `present` motion modifier for `omp target update` directives. The next patch in this series implements OpenMP runtime support. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D84711
2020-07-30 00:18:45 +08:00
if (Modifier == OMPC_MOTION_MODIFIER_unknown)
break;
Data.MotionModifiers.push_back(Modifier);
Data.MotionModifiersLoc.push_back(Tok.getLocation());
ConsumeToken();
[OpenMP][NFC] Consolidate `to` and `from` clause modifiers `to` and `from` clauses take the same modifiers, which are called "motion modifiers" in TR8, so implement handling of their modifiers once not twice. This will make it easier to implement additional motion modifiers in the future. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D84710
2020-07-29 06:06:05 +08:00
if (Modifier == OMPC_MOTION_MODIFIER_mapper) {
Revert "[OpenMP] Implement TR8 `present` motion modifier in Clang (1/2)" This reverts commit 3c3faae497046be706df29e16c9fbccb7e1fce09. It breaks a number of bots.
2020-07-29 08:26:56 +08:00
IsInvalidMapperModifier = parseMapperModifier(Data);
[OpenMP] Implement TR8 `present` motion modifier in Clang (1/2) This patch implements Clang front end support for the OpenMP TR8 `present` motion modifier for `omp target update` directives. The next patch in this series implements OpenMP runtime support. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D84711
2020-07-30 00:18:45 +08:00
if (IsInvalidMapperModifier)
break;
[OpenMP] Implement TR8 `present` motion modifier in Clang (1/2) This patch implements Clang front end support for the OpenMP TR8 `present` motion modifier for `omp target update` directives. The next patch in this series implements OpenMP runtime support. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D84711
2020-07-29 06:06:24 +08:00
}
[OpenMP] Implement TR8 `present` motion modifier in Clang (1/2) This patch implements Clang front end support for the OpenMP TR8 `present` motion modifier for `omp target update` directives. The next patch in this series implements OpenMP runtime support. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D84711
2020-07-30 00:18:45 +08:00
// OpenMP < 5.1 doesn't permit a ',' or additional modifiers.
if (getLangOpts().OpenMP < 51)
break;
// OpenMP 5.1 accepts an optional ',' even if the next character is ':'.
// TODO: Is that intentional?
if (Tok.is(tok::comma))
ConsumeToken();
}
if (!Data.MotionModifiers.empty() && Tok.isNot(tok::colon)) {
if (!IsInvalidMapperModifier) {
if (getLangOpts().OpenMP < 51)
Diag(Tok, diag::warn_pragma_expected_colon) << ")";
else
Diag(Tok, diag::warn_pragma_expected_colon) << "motion modifier";
}
SkipUntil(tok::colon, tok::r_paren, tok::annot_pragma_openmp_end,
StopBeforeMatch);
[OpenMP 5.0] Parsing/sema support for to clause with mapper modifier. This patch implements the parsing and sema support for OpenMP to clause with potential user-defined mappers attached. User defined mapper is a new feature in OpenMP 5.0. A to/from clause can have an explicit or implicit associated mapper, which instructs the compiler to generate and use customized mapping functions. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target update to(mapper(id): ss) // use the mapper with name 'id' to map ss to device Contributed-by: <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58523 llvm-svn: 354698
2019-02-23 06:29:42 +08:00
}
[OpenMP] Implement TR8 `present` motion modifier in Clang (1/2) This patch implements Clang front end support for the OpenMP TR8 `present` motion modifier for `omp target update` directives. The next patch in this series implements OpenMP runtime support. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D84711
2020-07-30 00:18:45 +08:00
// OpenMP 5.1 permits a ':' even without a preceding modifier. TODO: Is
// that intentional?
if ((!Data.MotionModifiers.empty() || getLangOpts().OpenMP >= 51) &&
Tok.is(tok::colon))
Data.ColonLoc = ConsumeToken();
[OPENMP50]Add initial support for 'affinity' clause. Summary: Added parsing/sema/serialization support for affinity clause in task directives. Reviewers: jdoerfert Subscribers: yaxunl, guansong, arphaman, llvm-commits, cfe-commits, caomhin Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D80148
2020-05-19 01:37:53 +08:00
} else if (Kind == OMPC_allocate ||
(Kind == OMPC_affinity && Tok.is(tok::identifier) &&
PP.getSpelling(Tok) == "iterator")) {
[OPENMP]Initial support for 'allocate' clause. Added parsing/sema analysis of the allocate clause. llvm-svn: 357068
2019-03-27 22:14:31 +08:00
// Handle optional allocator expression followed by colon delimiter.
ColonProtectionRAIIObject ColonRAII(*this);
TentativeParsingAction TPA(*this);
[OPENMP50]Add initial support for 'affinity' clause. Summary: Added parsing/sema/serialization support for affinity clause in task directives. Reviewers: jdoerfert Subscribers: yaxunl, guansong, arphaman, llvm-commits, cfe-commits, caomhin Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D80148
2020-05-19 01:37:53 +08:00
// OpenMP 5.0, 2.10.1, task Construct.
// where aff-modifier is one of the following:
// iterator(iterators-definition)
ExprResult Tail;
if (Kind == OMPC_allocate) {
Tail = ParseAssignmentExpression();
} else {
HasIterator = true;
EnterScope(Scope::OpenMPDirectiveScope | Scope::DeclScope);
Tail = ParseOpenMPIteratorsExpr();
}
Tail = Actions.CorrectDelayedTyposInExpr(Tail);
[OPENMP]Initial support for 'allocate' clause. Added parsing/sema analysis of the allocate clause. llvm-svn: 357068
2019-03-27 22:14:31 +08:00
Tail = Actions.ActOnFinishFullExpr(Tail.get(), T.getOpenLocation(),
/*DiscardedValue=*/false);
if (Tail.isUsable()) {
if (Tok.is(tok::colon)) {
[OPENMP50]Add initial support for OpenMP 5.0 iterator. Added basic parsing/semantic analysis/(de)serialization support for iterator expression introduced in OpenMP 5.0.
2020-04-02 03:06:38 +08:00
Data.DepModOrTailExpr = Tail.get();
[OPENMP]Initial support for 'allocate' clause. Added parsing/sema analysis of the allocate clause. llvm-svn: 357068
2019-03-27 22:14:31 +08:00
Data.ColonLoc = ConsumeToken();
TPA.Commit();
} else {
[OPENMP50]Add initial support for 'affinity' clause. Summary: Added parsing/sema/serialization support for affinity clause in task directives. Reviewers: jdoerfert Subscribers: yaxunl, guansong, arphaman, llvm-commits, cfe-commits, caomhin Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D80148
2020-05-19 01:37:53 +08:00
// Colon not found, parse only list of variables.
[OPENMP]Initial support for 'allocate' clause. Added parsing/sema analysis of the allocate clause. llvm-svn: 357068
2019-03-27 22:14:31 +08:00
TPA.Revert();
}
} else {
// Parsing was unsuccessfull, revert and skip to the end of clause or
// directive.
TPA.Revert();
SkipUntil(tok::comma, tok::r_paren, tok::annot_pragma_openmp_end,
StopBeforeMatch);
}
[OPENMP51]Initial parsing/sema for adjust_args clause for 'declare variant' Adds initial parsing and sema for the 'adjust_args' clause. Note that an AST clause is not created as it instead adds its expressions to the OMPDeclareVariantAttr. Differential Revision: https://reviews.llvm.org/D99905
2021-10-13 05:55:00 +08:00
} else if (Kind == OMPC_adjust_args) {
// Handle adjust-op for adjust_args clause.
ColonProtectionRAIIObject ColonRAII(*this);
Data.ExtraModifier = getOpenMPSimpleClauseType(
Kind, Tok.is(tok::identifier) ? PP.getSpelling(Tok) : "",
getLangOpts());
Data.ExtraModifierLoc = Tok.getLocation();
if (Data.ExtraModifier == OMPC_ADJUST_ARGS_unknown) {
SkipUntil(tok::colon, tok::r_paren, tok::annot_pragma_openmp_end,
StopBeforeMatch);
} else {
ConsumeToken();
if (Tok.is(tok::colon))
Data.ColonLoc = Tok.getLocation();
ExpectAndConsume(tok::colon, diag::warn_pragma_expected_colon,
"adjust-op");
}
[OPENMP] Initial support of 'reduction' clause llvm-svn: 211007
2014-06-16 15:08:35 +08:00
}
[OPENMP] Initial support for 'in_reduction' clause. Parsing/sema analysis for 'in_reduction' clause for task-based directives. llvm-svn: 308768
2017-07-22 02:48:21 +08:00
bool IsComma =
(Kind != OMPC_reduction && Kind != OMPC_task_reduction &&
Kind != OMPC_in_reduction && Kind != OMPC_depend && Kind != OMPC_map) ||
(Kind == OMPC_reduction && !InvalidReductionId) ||
[OPENMP50]Basic support for conditional lastprivate. Added parsing/sema checks for conditional lastprivates.
2019-12-21 00:04:57 +08:00
(Kind == OMPC_map && Data.ExtraModifier != OMPC_MAP_unknown) ||
[OPENMP51]Initial parsing/sema for adjust_args clause for 'declare variant' Adds initial parsing and sema for the 'adjust_args' clause. Note that an AST clause is not created as it instead adds its expressions to the OMPDeclareVariantAttr. Differential Revision: https://reviews.llvm.org/D99905
2021-10-13 05:55:00 +08:00
(Kind == OMPC_depend && Data.ExtraModifier != OMPC_DEPEND_unknown) ||
(Kind == OMPC_adjust_args &&
Data.ExtraModifier != OMPC_ADJUST_ARGS_unknown);
Parsing/Sema for OMPAlignedClause. llvm-svn: 209816
2014-05-29 22:36:25 +08:00
const bool MayHaveTail = (Kind == OMPC_linear || Kind == OMPC_aligned);
[OPENMP] parsing 'linear' clause (for directive 'omp simd') Differential Revision: http://reviews.llvm.org/D3272 llvm-svn: 206891
2014-04-22 21:09:42 +08:00
while (IsComma || (Tok.isNot(tok::r_paren) && Tok.isNot(tok::colon) &&
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
Tok.isNot(tok::annot_pragma_openmp_end))) {
[OPENMP50]Add initial support for OpenMP 5.0 iterator. Added basic parsing/semantic analysis/(de)serialization support for iterator expression introduced in OpenMP 5.0.
2020-04-02 03:06:38 +08:00
ParseScope OMPListScope(this, Scope::OpenMPDirectiveScope);
[OPENMP] parsing 'linear' clause (for directive 'omp simd') Differential Revision: http://reviews.llvm.org/D3272 llvm-svn: 206891
2014-04-22 21:09:42 +08:00
ColonProtectionRAIIObject ColonRAII(*this, MayHaveTail);
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
// Parse variable
Enable ActOnIdExpression to use delayed typo correction for non-C++ code when calling DiagnoseEmptyLookup. llvm-svn: 222551
2014-11-22 02:48:04 +08:00
ExprResult VarExpr =
Actions.CorrectDelayedTyposInExpr(ParseAssignmentExpression());
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-24 03:53:05 +08:00
if (VarExpr.isUsable()) {
Refactoring. Remove release and take methods from ActionResult. Rename takeAs to getAs. llvm-svn: 209800
2014-05-29 18:55:11 +08:00
Vars.push_back(VarExpr.get());
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-24 03:53:05 +08:00
} else {
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
SkipUntil(tok::comma, tok::r_paren, tok::annot_pragma_openmp_end,
Revert "[OPENMP] Fix for parsing OpenMP directives with extra braces, brackets and parens" These parser changes were redundant. The same or better recovery can be achieved with a one-line fix to SkipUntil() due to land in the next commit. This reverts commit r197553. llvm-svn: 197597
2013-12-19 03:10:49 +08:00
StopBeforeMatch);
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
}
// Skip ',' if any
IsComma = Tok.is(tok::comma);
Revert "[OPENMP] Allow skip expression after comma in clauses with lists." This reverts commit http://reviews.llvm.org/rL265003. After some thoughts decided to emit errors here. llvm-svn: 265119
2016-04-01 16:43:42 +08:00
if (IsComma)
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
ConsumeToken();
Revert "[OPENMP] Allow skip expression after comma in clauses with lists." This reverts commit http://reviews.llvm.org/rL265003. After some thoughts decided to emit errors here. llvm-svn: 265119
2016-04-01 16:43:42 +08:00
else if (Tok.isNot(tok::r_paren) &&
[OPENMP] parsing 'linear' clause (for directive 'omp simd') Differential Revision: http://reviews.llvm.org/D3272 llvm-svn: 206891
2014-04-22 21:09:42 +08:00
Tok.isNot(tok::annot_pragma_openmp_end) &&
(!MayHaveTail || Tok.isNot(tok::colon)))
[OPENMP] Initial parsing and sema analysis for 'flush' directive. llvm-svn: 213512
2014-07-21 19:26:11 +08:00
Diag(Tok, diag::err_omp_expected_punc)
<< ((Kind == OMPC_flush) ? getOpenMPDirectiveName(OMPD_flush)
: getOpenMPClauseName(Kind))
<< (Kind == OMPC_flush);
[OPENMP] parsing 'linear' clause (for directive 'omp simd') Differential Revision: http://reviews.llvm.org/D3272 llvm-svn: 206891
2014-04-22 21:09:42 +08:00
}
[OPENMP 4.1] Initial support for modifiers in 'linear' clause. OpenMP 4.1 adds 3 optional modifiers to 'linear' clause. Format of 'linear' clause has changed to: ``` linear(linear-list[ : linear-step]) ``` where linear-list is one of the following ``` list modifier(list) ``` where modifier is one of the following: ``` ref (C++) val (C/C++) uval (C++) ``` Patch adds parsing and sema analysis for these modifiers. llvm-svn: 245550
2015-08-20 18:54:39 +08:00
// Parse ')' for linear clause with modifier.
if (NeedRParenForLinear)
LinearT.consumeClose();
Parsing/Sema for OMPAlignedClause. llvm-svn: 209816
2014-05-29 22:36:25 +08:00
// Parse ':' linear-step (or ':' alignment).
[OPENMP] parsing 'linear' clause (for directive 'omp simd') Differential Revision: http://reviews.llvm.org/D3272 llvm-svn: 206891
2014-04-22 21:09:42 +08:00
const bool MustHaveTail = MayHaveTail && Tok.is(tok::colon);
if (MustHaveTail) {
[OPENMP 4.0] Support for 'uniform' clause in 'declare simd' directive. OpenMP 4.0 defines clause 'uniform' in 'declare simd' directive: 'uniform' '(' <argument-list> ')' The uniform clause declares one or more arguments to have an invariant value for all concurrent invocations of the function in the execution of a single SIMD loop. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266041
2016-04-12 13:28:34 +08:00
Data.ColonLoc = Tok.getLocation();
[OPENMP 4.1] Parsing/sema analysis for extended format of 'if' clause. OpenMP 4.1 added special 'directive-name-modifier' to the 'if' clause. Format of 'if' clause is as follows: ``` if([ directive-name-modifier :] scalar-logical-expression) ``` The restriction rules are also changed. 1. If any 'if' clause on the directive includes a 'directive-name-modifier' then all 'if' clauses on the directive must include a 'directive-name-modifier'. 2. At most one 'if' clause without a 'directive-name-modifier' can appear on the directive. 3. At most one 'if' clause with some particular 'directive-name-modifier' can appear on the directive. 'directive-name-modifier' is important for combined directives and allows to separate conditions in 'if' clause for simple sub-directives in combined directive. This 'directive-name-modifier' identifies the sub-directive to which this 'if' clause must be applied. llvm-svn: 246747
2015-09-03 15:23:48 +08:00
SourceLocation ELoc = ConsumeToken();
ExprResult Tail = ParseAssignmentExpression();
Refactor the way we handle diagnosing unused expression results. Rather than sprinkle calls to DiagnoseUnusedExprResult() around in places where we want diagnostics, we now diagnose unused expression statements and full expressions in a more generic way when acting on the final expression statement. This results in more appropriate diagnostics for [[nodiscard]] where we were previously lacking them, such as when the body of a for loop is not a compound statement. This patch fixes PR39837. llvm-svn: 350404
2019-01-05 00:58:14 +08:00
Tail =
Actions.ActOnFinishFullExpr(Tail.get(), ELoc, /*DiscardedValue*/ false);
[OPENMP] parsing 'linear' clause (for directive 'omp simd') Differential Revision: http://reviews.llvm.org/D3272 llvm-svn: 206891
2014-04-22 21:09:42 +08:00
if (Tail.isUsable())
[OPENMP50]Add initial support for OpenMP 5.0 iterator. Added basic parsing/semantic analysis/(de)serialization support for iterator expression introduced in OpenMP 5.0.
2020-04-02 03:06:38 +08:00
Data.DepModOrTailExpr = Tail.get();
[OPENMP] parsing 'linear' clause (for directive 'omp simd') Differential Revision: http://reviews.llvm.org/D3272 llvm-svn: 206891
2014-04-22 21:09:42 +08:00
else
SkipUntil(tok::comma, tok::r_paren, tok::annot_pragma_openmp_end,
StopBeforeMatch);
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
}
// Parse ')'.
[OPENMP] Make clauses closing loc point to right bracket. For some of the clauses the closing location erroneously points to the beginning of the next clause rather than on the location of the closing bracket of the clause. llvm-svn: 336460
2018-07-07 03:35:42 +08:00
Data.RLoc = Tok.getLocation();
if (!T.consumeClose())
Data.RLoc = T.getCloseLocation();
[OPENMP50]Add initial support for OpenMP 5.0 iterator. Added basic parsing/semantic analysis/(de)serialization support for iterator expression introduced in OpenMP 5.0.
2020-04-02 03:06:38 +08:00
// Exit from scope when the iterator is used in depend clause.
[OPENMP50]Add initial support for 'affinity' clause. Summary: Added parsing/sema/serialization support for affinity clause in task directives. Reviewers: jdoerfert Subscribers: yaxunl, guansong, arphaman, llvm-commits, cfe-commits, caomhin Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D80148
2020-05-19 01:37:53 +08:00
if (HasIterator)
[OPENMP50]Add initial support for OpenMP 5.0 iterator. Added basic parsing/semantic analysis/(de)serialization support for iterator expression introduced in OpenMP 5.0.
2020-04-02 03:06:38 +08:00
ExitScope();
[OPENMP50]Add 'depobj' modifier in 'depend' clauses. Added basic support (parsing/sema/serialization) for depobj dependency kind in depend clauses.
2020-03-07 00:09:55 +08:00
return (Kind != OMPC_depend && Kind != OMPC_map && Vars.empty()) ||
[OPENMP50]Add initial support for OpenMP 5.0 iterator. Added basic parsing/semantic analysis/(de)serialization support for iterator expression introduced in OpenMP 5.0.
2020-04-02 03:06:38 +08:00
(MustHaveTail && !Data.DepModOrTailExpr) || InvalidReductionId ||
[OpenMP 5.0] Parsing/sema support for to clause with mapper modifier. This patch implements the parsing and sema support for OpenMP to clause with potential user-defined mappers attached. User defined mapper is a new feature in OpenMP 5.0. A to/from clause can have an explicit or implicit associated mapper, which instructs the compiler to generate and use customized mapping functions. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target update to(mapper(id): ss) // use the mapper with name 'id' to map ss to device Contributed-by: <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58523 llvm-svn: 354698
2019-02-23 06:29:42 +08:00
IsInvalidMapperModifier;
[OPENMP 4.0] Support for 'uniform' clause in 'declare simd' directive. OpenMP 4.0 defines clause 'uniform' in 'declare simd' directive: 'uniform' '(' <argument-list> ')' The uniform clause declares one or more arguments to have an invariant value for all concurrent invocations of the function in the execution of a single SIMD loop. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266041
2016-04-12 13:28:34 +08:00
}
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Parsing of OpenMP clause 'private', 'firstprivate', 'lastprivate',
[OPENMP50]Initial support for inclusive clause. Added parsing/sema/serialization support for inclusive clause in scan directive.
2020-03-20 21:41:22 +08:00
/// 'shared', 'copyin', 'copyprivate', 'flush', 'reduction', 'task_reduction',
[OPENMP50]Bassic support for exclusive clause. Added basic support (parsing/sema/serialization) for exclusive clause in scan directives.
2020-03-23 22:41:08 +08:00
/// 'in_reduction', 'nontemporal', 'exclusive' or 'inclusive'.
[OPENMP 4.0] Support for 'uniform' clause in 'declare simd' directive. OpenMP 4.0 defines clause 'uniform' in 'declare simd' directive: 'uniform' '(' <argument-list> ')' The uniform clause declares one or more arguments to have an invariant value for all concurrent invocations of the function in the execution of a single SIMD loop. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266041
2016-04-12 13:28:34 +08:00
///
/// private-clause:
/// 'private' '(' list ')'
/// firstprivate-clause:
/// 'firstprivate' '(' list ')'
/// lastprivate-clause:
/// 'lastprivate' '(' list ')'
/// shared-clause:
/// 'shared' '(' list ')'
/// linear-clause:
/// 'linear' '(' linear-list [ ':' linear-step ] ')'
/// aligned-clause:
/// 'aligned' '(' list [ ':' alignment ] ')'
/// reduction-clause:
[OPENMP50]Add 'default' modifier in reduction clauses. Added full support for 'default' modifier in the reduction clauses.
2020-03-24 05:30:38 +08:00
/// 'reduction' '(' [ modifier ',' ] reduction-identifier ':' list ')'
[OPENMP] Initial support for 'task_reduction' clause. Parsing/sema analysis of the 'task_reduction' clause. llvm-svn: 308352
2017-07-19 04:17:46 +08:00
/// task_reduction-clause:
/// 'task_reduction' '(' reduction-identifier ':' list ')'
[OPENMP] Initial support for 'in_reduction' clause. Parsing/sema analysis for 'in_reduction' clause for task-based directives. llvm-svn: 308768
2017-07-22 02:48:21 +08:00
/// in_reduction-clause:
/// 'in_reduction' '(' reduction-identifier ':' list ')'
[OPENMP 4.0] Support for 'uniform' clause in 'declare simd' directive. OpenMP 4.0 defines clause 'uniform' in 'declare simd' directive: 'uniform' '(' <argument-list> ')' The uniform clause declares one or more arguments to have an invariant value for all concurrent invocations of the function in the execution of a single SIMD loop. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266041
2016-04-12 13:28:34 +08:00
/// copyprivate-clause:
/// 'copyprivate' '(' list ')'
/// flush-clause:
/// 'flush' '(' list ')'
/// depend-clause:
/// 'depend' '(' in | out | inout : list | source ')'
/// map-clause:
[OPENMP] parsing and sema support for 'close' map-type-modifier A map clause with the close map-type-modifier is a hint to prefer that the variables are mapped using a copy into faster memory. Patch by Ahsan Saghir (saghir) Differential Revision: https://reviews.llvm.org/D55719 llvm-svn: 349551
2018-12-19 06:18:41 +08:00
/// 'map' '(' [ [ always [,] ] [ close [,] ]
[OpenMP 5.0] Parsing/sema support for to clause with mapper modifier. This patch implements the parsing and sema support for OpenMP to clause with potential user-defined mappers attached. User defined mapper is a new feature in OpenMP 5.0. A to/from clause can have an explicit or implicit associated mapper, which instructs the compiler to generate and use customized mapping functions. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target update to(mapper(id): ss) // use the mapper with name 'id' to map ss to device Contributed-by: <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58523 llvm-svn: 354698
2019-02-23 06:29:42 +08:00
/// [ mapper '(' mapper-identifier ')' [,] ]
[OPENMP 4.0] Support for 'uniform' clause in 'declare simd' directive. OpenMP 4.0 defines clause 'uniform' in 'declare simd' directive: 'uniform' '(' <argument-list> ')' The uniform clause declares one or more arguments to have an invariant value for all concurrent invocations of the function in the execution of a single SIMD loop. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266041
2016-04-12 13:28:34 +08:00
/// to | from | tofrom | alloc | release | delete ':' ] list ')';
[OpenMP] Parsing and sema support for the to clause Summary: The patch contains the parsing and sema support for the `to` clause. Patch based on the original post by Kelvin Li. Reviewers: carlo.bertolli, hfinkel, kkwli0, arpith-jacob, ABataev Subscribers: caomhin, cfe-commits Differential Revision: http://reviews.llvm.org/D18597 llvm-svn: 270880
2016-05-27 01:39:58 +08:00
/// to-clause:
[OpenMP 5.0] Parsing/sema support for to clause with mapper modifier. This patch implements the parsing and sema support for OpenMP to clause with potential user-defined mappers attached. User defined mapper is a new feature in OpenMP 5.0. A to/from clause can have an explicit or implicit associated mapper, which instructs the compiler to generate and use customized mapping functions. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target update to(mapper(id): ss) // use the mapper with name 'id' to map ss to device Contributed-by: <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58523 llvm-svn: 354698
2019-02-23 06:29:42 +08:00
/// 'to' '(' [ mapper '(' mapper-identifier ')' ':' ] list ')'
[OpenMP] Parsing and sema support for the from clause Summary: The patch contains the parsing and sema support for the `from` clause. Patch based on the original post by Kelvin Li. Reviewers: hfinkel, carlo.bertolli, kkwli0, arpith-jacob, ABataev Subscribers: caomhin, cfe-commits Differential Revision: http://reviews.llvm.org/D18488 llvm-svn: 270882
2016-05-27 01:49:04 +08:00
/// from-clause:
[OpenMP 5.0] Parsing/sema support for from clause with mapper modifier. This patch implements the parsing and sema support for the OpenMP 'from'-clause with potential user-defined mappers attached. User-defined mappers are a new feature in OpenMP 5.0. A 'from'-clause can have an explicit or implicit associated mapper, which instructs the compiler to generate and use customized mapping functions. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target update from(mapper(id): ss) // use the mapper with name 'id' to map ss from device Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58638 llvm-svn: 354817
2019-02-26 04:34:15 +08:00
/// 'from' '(' [ mapper '(' mapper-identifier ')' ':' ] list ')'
[OpenMP] Initial implementation of parse+sema for clause use_device_ptr of 'target data' http://reviews.llvm.org/D21904 This patch is similar to the implementation of 'private' clause: it adds a list of private pointers to be used within the target data region to store the device pointers returned by the runtime. Please refer to the following document for a full description of what the runtime witll return in this case (page 10 and 11): https://github.com/clang-omp/OffloadingDesign I am happy to answer any question related to the runtime interface to help reviewing this patch. llvm-svn: 275271
2016-07-13 23:37:16 +08:00
/// use_device_ptr-clause:
/// 'use_device_ptr' '(' list ')'
[OPENMP50]Initial support for use_device_addr clause. Summary: Added parsing/sema analysis/serialization support for use_device_addr clauses. Reviewers: jdoerfert Subscribers: yaxunl, guansong, arphaman, sstefan1, llvm-commits, cfe-commits, caomhin Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D80404
2020-05-21 20:30:23 +08:00
/// use_device_addr-clause:
/// 'use_device_addr' '(' list ')'
[OpenMP] Initial implementation of parse+sema for OpenMP clause 'is_device_ptr' of target http://reviews.llvm.org/D22070 llvm-svn: 275282
2016-07-14 01:16:49 +08:00
/// is_device_ptr-clause:
/// 'is_device_ptr' '(' list ')'
[OPENMP]Initial support for 'allocate' clause. Added parsing/sema analysis of the allocate clause. llvm-svn: 357068
2019-03-27 22:14:31 +08:00
/// allocate-clause:
/// 'allocate' '(' [ allocator ':' ] list ')'
[OPENMP50]Initial support for inclusive clause. Added parsing/sema/serialization support for inclusive clause in scan directive.
2020-03-20 21:41:22 +08:00
/// nontemporal-clause:
/// 'nontemporal' '(' list ')'
/// inclusive-clause:
/// 'inclusive' '(' list ')'
[OPENMP50]Bassic support for exclusive clause. Added basic support (parsing/sema/serialization) for exclusive clause in scan directives.
2020-03-23 22:41:08 +08:00
/// exclusive-clause:
/// 'exclusive' '(' list ')'
[OPENMP 4.0] Support for 'uniform' clause in 'declare simd' directive. OpenMP 4.0 defines clause 'uniform' in 'declare simd' directive: 'uniform' '(' <argument-list> ')' The uniform clause declares one or more arguments to have an invariant value for all concurrent invocations of the function in the execution of a single SIMD loop. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266041
2016-04-12 13:28:34 +08:00
///
/// For 'linear' clause linear-list may have the following forms:
/// list
/// modifier(list)
/// where modifier is 'val' (C) or 'ref', 'val' or 'uval'(C++).
OMPClause *Parser::ParseOpenMPVarListClause(OpenMPDirectiveKind DKind,
[OpenMP] Fix handling of clause on wrong directive, by Joel. E. Denny Summary: First, this patch fixes an assert failure when, for example, "omp for" has num_teams. Second, this patch prevents duplicate diagnostics when, for example, "omp for" has uniform. This patch makes the general assumption (even where it doesn't necessarily fix an existing bug) that it is worthless to perform sema for a clause that appears on a directive on which OpenMP does not permit that clause. However, due to this assumption, this patch suppresses some diagnostics that were expected in the test suite. I assert that those diagnostics were likely just distracting to the user. Reviewers: ABataev Reviewed By: ABataev Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D41841 llvm-svn: 322107
2018-01-10 03:21:04 +08:00
OpenMPClauseKind Kind,
bool ParseOnly) {
[OPENMP 4.0] Support for 'uniform' clause in 'declare simd' directive. OpenMP 4.0 defines clause 'uniform' in 'declare simd' directive: 'uniform' '(' <argument-list> ')' The uniform clause declares one or more arguments to have an invariant value for all concurrent invocations of the function in the execution of a single SIMD loop. The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses. llvm-svn: 266041
2016-04-12 13:28:34 +08:00
SourceLocation Loc = Tok.getLocation();
SourceLocation LOpen = ConsumeToken();
SmallVector<Expr *, 4> Vars;
OpenMPVarListDataTy Data;
if (ParseOpenMPVarList(DKind, Kind, Vars, Data))
[C++11] Use 'nullptr'. Parser edition. llvm-svn: 209275
2014-05-21 14:02:52 +08:00
return nullptr;
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
[OpenMP] Fix handling of clause on wrong directive, by Joel. E. Denny Summary: First, this patch fixes an assert failure when, for example, "omp for" has num_teams. Second, this patch prevents duplicate diagnostics when, for example, "omp for" has uniform. This patch makes the general assumption (even where it doesn't necessarily fix an existing bug) that it is worthless to perform sema for a clause that appears on a directive on which OpenMP does not permit that clause. However, due to this assumption, this patch suppresses some diagnostics that were expected in the test suite. I assert that those diagnostics were likely just distracting to the user. Reviewers: ABataev Reviewed By: ABataev Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D41841 llvm-svn: 322107
2018-01-10 03:21:04 +08:00
if (ParseOnly)
return nullptr;
[OpenMP 5.0] Parsing/sema support for map clause with mapper modifier. This patch implements the parsing and sema support for OpenMP map clauses with potential user-defined mapper attached. User defined mapper is a new feature in OpenMP 5.0. A map clause can have an explicit or implicit associated mapper, which instructs the compiler to generate extra data mapping. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target map(mapper(id) tofrom: ss) // use the mapper with name 'id' to map ss Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58074 llvm-svn: 354347
2019-02-20 00:38:20 +08:00
OMPVarListLocTy Locs(Loc, LOpen, Data.RLoc);
[OPENMP] Initial support of 'reduction' clause llvm-svn: 211007
2014-06-16 15:08:35 +08:00
return Actions.ActOnOpenMPVarListClause(
[OPENMP50]Add initial support for OpenMP 5.0 iterator. Added basic parsing/semantic analysis/(de)serialization support for iterator expression introduced in OpenMP 5.0.
2020-04-02 03:06:38 +08:00
Kind, Vars, Data.DepModOrTailExpr, Locs, Data.ColonLoc,
[OPENMP50]Basic support for conditional lastprivate. Added parsing/sema checks for conditional lastprivates.
2019-12-21 00:04:57 +08:00
Data.ReductionOrMapperIdScopeSpec, Data.ReductionOrMapperId,
Data.ExtraModifier, Data.MapTypeModifiers, Data.MapTypeModifiersLoc,
[OpenMP] Implement TR8 `present` motion modifier in Clang (1/2) This patch implements Clang front end support for the OpenMP TR8 `present` motion modifier for `omp target update` directives. The next patch in this series implements OpenMP runtime support. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D84711
2020-07-30 00:18:45 +08:00
Data.IsMapTypeImplicit, Data.ExtraModifierLoc, Data.MotionModifiers,
Data.MotionModifiersLoc);
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 11:13:43 +08:00
}