mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-25 12:56:06 +00:00
Code Issues Projects 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.

5274 lines
193 KiB
C++
Raw Normal View History

OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 06:34:35 +00: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 08:50:56 +00: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 06:34:35 +00: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 01:00:01 +00:00
/// This file implements parsing of all OpenMP directives and clauses.
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 06:34:35 +00:00
///
//===----------------------------------------------------------------------===//
[OPENMP] Initial codegen for '#pragma omp parallel' llvm-svn: 208077
2014-05-06 10:08:46 +00: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-03 12:35:30 -07:00
#include "clang/AST/OpenMPClause.h"
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00:00
#include "clang/AST/StmtOpenMP.h"
[Parse] Remove ParseDiagnostic.h (#116496) This patch removes clang/Parse/ParseDiagnostic.h because it just forwards to clang/Basic/DiagnosticParse.h.
2024-11-18 07:19:33 -08:00
#include "clang/Basic/DiagnosticParse.h"
[OPENMP50]Basic support for conditional lastprivate. Added parsing/sema checks for conditional lastprivates.
2019-12-20 11:04:57 -05: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-25 14: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-23 17:30:38 -04:00
#include "clang/Basic/TokenKinds.h"
OpenMP threadprivate with qualified names. llvm-svn: 181683
2013-05-13 04:18:18 +00: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 15:11:07 +00:00
#include "clang/Parse/RAIIObjectsForParser.h"
[clang][Sema][NFC] Move `EnterExpressionEvaluationContext` to its own file Sema.h is huge. This makes a small reduction to it by moving EnterExpressionEvaluationContext into a new header, since it is an independent component. Differential Revision: https://reviews.llvm.org/D149796
2023-05-04 13:06:53 -04:00
#include "clang/Sema/EnterExpressionEvaluationContext.h"
OpenMP threadprivate with qualified names. llvm-svn: 181683
2013-05-13 04:18:18 +00:00
#include "clang/Sema/Scope.h"
[clang] Introduce target-specific `Sema` components (#93179) This patch introduces `SemaAMDGPU`, `SemaARM`, `SemaBPF`, `SemaHexagon`, `SemaLoongArch`, `SemaMIPS`, `SemaNVPTX`, `SemaPPC`, `SemaSystemZ`, `SemaWasm`. This continues previous efforts to split Sema up. Additional context can be found in #84184 and #92682. I decided to bundle target-specific components together because of their low impact on `Sema`. That said, their impact on `SemaChecking.cpp` is far from low, and I consider it a success. Somewhat accidentally, I also moved Wasm- and AMDGPU-specific function from `SemaDeclAttr.cpp`, because they were exposed in `Sema`. That went well, and I consider it a success, too. I'd like to move the rest of static target-specific functions out of `SemaDeclAttr.cpp` like we're doing with built-ins in `SemaChecking.cpp` .
2024-05-30 19:59:59 +04:00
#include "clang/Sema/SemaAMDGPU.h"
[clang] Introduce `SemaCodeCompletion` (#92311) This patch continues previous efforts to split `Sema` up, this time covering code completion. Context can be found in #84184. Dropping `Code` prefix from function names in `SemaCodeCompletion` would make sense, but I think this PR has enough changes already. As usual, formatting changes are done as a separate commit. Hopefully this helps with the review.
2024-05-17 20:55:37 +04:00
#include "clang/Sema/SemaCodeCompletion.h"
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
#include "clang/Sema/SemaOpenMP.h"
[clang][OpenMP] Shorten directive classification in ParseOpenMP (#94691) Use directive categories to simplify long lists of `case` statements in the OpenMP parser. This is a step towards avoiding dependence on explicitly specified sets of directives that can be expressed more generically. The upcoming OpenMP 6.0 will introduce many new combined directives, and the more generically we handle directives, the easier the introduction of the new standard will be. --------- Co-authored-by: Alexey Bataev <a.bataev@outlook.com>
2024-06-26 08:11:09 -05:00
#include "llvm/ADT/SmallBitVector.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-23 11:48:59 -06:00
#include "llvm/ADT/StringSwitch.h"
[OpenMP][NFC] Extract assumption helpers into own header file
2021-11-04 08:48:19 -05:00
#include "llvm/Frontend/OpenMP/OMPAssume.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-19 20:42:12 -06:00
#include "llvm/Frontend/OpenMP/OMPContext.h"
[clang] Add #include <optional> (NFC) This patch adds #include <optional> to those files containing llvm::Optional<...> or Optional<...>. I'll post a separate patch to actually replace llvm::Optional with std::optional. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2023-01-14 11:07:21 -08:00
#include <optional>
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 13:44:28 +00:00
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 06:34:35 +00: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-04 22:00:49 -06:00
using namespace llvm::omp;
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 06:34:35 +00: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 06:53:38 +00: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 09:29:50 -04: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 06:53:38 +00: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 05:21:39 +00: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 11:38:59 +00: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 06:53:38 +00: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 05:21:39 +00: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 06:53:38 +00: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-26 17:30:50 +00: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-11-30 23:51:03 +00: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-29 22:16:30 +00: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-01 20:25:04 +00: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-13 20:18:17 +00: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-20 19:50:47 -06: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 06:53:38 +00: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 14:59:13 +00: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-04 22:00:49 -06: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 10:41:35 +00: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-04 22:00:49 -06: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-07 17:54:44 +00: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 14:59:13 +00: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-07 17:54:44 +00: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 14:59:13 +00: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-07 17:54:44 +00: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 14:59:13 +00:00
void operator()(CXXScopeSpec &SS, DeclarationNameInfo NameInfo) {
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
ExprResult Res = P->getActions().OpenMP().ActOnOpenMPIdExpression(
[OPENMP 5.0]Add initial support for 'allocate' directive. Added parsing/sema analysis/serialization/deserialization support for 'allocate' directive. llvm-svn: 355614
2019-03-07 17:54:44 +00:00
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 14:59:13 +00: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 06:53:38 +00: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-04 22:00:49 -06: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 06:53:38 +00: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-04 22:00:49 -06: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 06:53:38 +00: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 05:21:39 +00: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 11:38:59 +00: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 06:53:38 +00: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 05:21:39 +00: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-26 17:30:50 +00: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-01 20:25:04 +00: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-13 20:18:17 +00: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-20 19:50:47 -06: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 06:53:38 +00: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-04 22:00:49 -06:00
static OpenMPDirectiveKindExWrapper parseOpenMPDirectiveKind(Parser &P) {
Parsing/Sema of directive omp for simd llvm-svn: 218029
2014-09-18 05:12:34 +00: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-04 22:00:49 -06: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-20 19:50:47 -06: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-23 11:48:59 -06: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-20 19:50:47 -06: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-23 11:48:59 -06:00
{OMPD_end, OMPD_assumes, OMPD_end_assumes},
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-23 19:53:05 +00: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-01 20:25:04 +00:00
{OMPD_declare, OMPD_mapper, OMPD_declare_mapper},
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-23 19:53:05 +00: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-13 20:18:17 +00: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 00:57:28 -05: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-20 19:50:47 -06: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-23 19:53:05 +00: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},
[OpenMP] Initial parsing/sema for the 'omp parallel loop' construct Adds basic parsing/sema/serialization support for the #pragma omp parallel loop directive. Differential Revision: https://reviews.llvm.org/D122247
2022-03-22 10:55:21 -07:00
{OMPD_parallel, OMPD_loop, OMPD_parallel_loop},
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-23 19:53:05 +00:00
{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},
[OpenMP] Initial parsing/sema for the 'omp target parallel loop' construct Adds basic parsing/sema/serialization support for the #pragma omp target parallel loop directive. Differential Revision: https://reviews.llvm.org/D122359
2022-03-23 15:37:06 -07:00
{OMPD_target_parallel, OMPD_loop, OMPD_target_parallel_loop},
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-23 19:53:05 +00:00
{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},
[OpenMP] Initial parsing/sema for the 'omp teams loop' construct Adds basic parsing/sema/serialization support for the #pragma omp teams loop directive. Differential Revision: https://reviews.llvm.org/D121713
2022-03-15 08:35:59 -07:00
{OMPD_teams, OMPD_loop, OMPD_teams_loop},
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-23 19:53:05 +00:00
{OMPD_target, OMPD_teams, OMPD_target_teams},
{OMPD_target_teams, OMPD_distribute, OMPD_target_teams_distribute},
[OpenMP] Initial parsing/sema for the 'omp target teams loop' construct Adds basic parsing/sema/serialization support for the #pragma omp target teams loop directive. Differential Revision: https://reviews.llvm.org/D122028
2022-03-18 11:02:02 -07:00
{OMPD_target_teams, OMPD_loop, OMPD_target_teams_loop},
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-23 19:53:05 +00:00
{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-10 20:13:02 +00: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-14 17:17:41 +00:00
{OMPD_master, OMPD_taskloop, OMPD_master_taskloop},
[OpenMP] Initial parsing and sema support for 'masked taskloop' construct This patch gives basic parsing and semantic support for "masked taskloop" construct introduced in OpenMP 5.1 (section 2.16.7) Differential Revision: https://reviews.llvm.org/D128478
2022-06-24 08:42:21 -07:00
{OMPD_masked, OMPD_taskloop, OMPD_masked_taskloop},
[OPENMP50]Add support for master taskloop simd. Added trsing/semantics/codegen for combined construct master taskloop simd. llvm-svn: 375255
2019-10-18 16:47:35 +00:00
{OMPD_master_taskloop, OMPD_simd, OMPD_master_taskloop_simd},
[OpenMP] Initial parsing and sema support for 'masked taskloop simd' construct This patch gives basic parsing and semantic support for "masked taskloop simd" construct introduced in OpenMP 5.1 (section 2.16.8) Differential Revision: https://reviews.llvm.org/D128693
2022-06-28 14:35:43 -07:00
{OMPD_masked_taskloop, OMPD_simd, OMPD_masked_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-14 17:17:41 +00:00
{OMPD_parallel, OMPD_master, OMPD_parallel_master},
[OpenMP] Initial parsing and sema for 'parallel masked' construct Differential Revision: https://reviews.llvm.org/D127454
2022-06-16 16:32:30 -07:00
{OMPD_parallel, OMPD_masked, OMPD_parallel_masked},
[OPENMP50]Add support for parallel master taskloop simd directive. Added full support for parallel master taskloop simd directive.
2019-10-25 10:27:13 -04:00
{OMPD_parallel_master, OMPD_taskloop, OMPD_parallel_master_taskloop},
[OpenMP] Initial parsing and sema support for 'parallel masked taskloop' construct This patch gives basic parsing and semantic support for "parallel masked taskloop" construct introduced in OpenMP 5.1 (section 2.16.9) Differential Revision: https://reviews.llvm.org/D128834
2022-06-30 10:59:33 -07:00
{OMPD_parallel_masked, OMPD_taskloop, OMPD_parallel_masked_taskloop},
[OPENMP50]Add support for parallel master taskloop simd directive. Added full support for parallel master taskloop simd directive.
2019-10-25 10:27:13 -04:00
{OMPD_parallel_master_taskloop, OMPD_simd,
[OpenMP] Initial parsing and semantic support for 'parallel masked taskloop simd' construct This patch gives basic parsing and semantic support for "parallel masked taskloop simd" construct introduced in OpenMP 5.1 (section 2.16.10) Differential Revision: https://reviews.llvm.org/D128946
2022-06-30 17:08:17 -07:00
OMPD_parallel_master_taskloop_simd},
{OMPD_parallel_masked_taskloop, OMPD_simd,
OMPD_parallel_masked_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 05:21:39 +00:00
enum { CancellationPoint = 0, DeclareReduction = 1, TargetData = 2 };
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-23 19:53:05 +00: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-04 22:00:49 -06:00
OpenMPDirectiveKindExWrapper DKind =
[OPENMP] Added initial support for 'omp parallel for'. llvm-svn: 212453
2014-07-07 13:01:15 +00: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 06:53:38 +00: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 13:44:28 +00:00
Use range-based for loops (NFC)
2022-08-20 21:18:32 -07:00
for (const auto &I : F) {
if (DKind != 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 06:53:38 +00: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 13:44:28 +00: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 06:53:38 +00: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-04 22:00:49 -06: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 06:53:38 +00: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 13:44:28 +00:00
Use range-based for loops (NFC)
2022-08-20 21:18:32 -07:00
if (SDKind == 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 06:53:38 +00:00
P.ConsumeToken();
Use range-based for loops (NFC)
2022-08-20 21:18:32 -07:00
DKind = I[2];
[OPENMP] Added initial support for 'omp parallel for'. llvm-svn: 212453
2014-07-07 13:01:15 +00: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 09:17:15 -04: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 05:21:39 +00: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 10:19:46 +00: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 05:21:39 +00: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 10:19:46 +00: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 05:21:39 +00: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 10:19:46 +00:00
if (!WithOperator)
break;
[clang] LLVM_FALLTHROUGH => [[fallthrough]]. NFC With C++17 there is no Clang pedantic warning or MSVC C5051. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D131346
2022-08-08 09:12:46 -07:00
[[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 05:21:39 +00: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 01:00:01 +00: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 05:21:39 +00: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-04 22:00:49 -06: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 05:21:39 +00: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 10:19:46 +00: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 05:21:39 +00: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-10 23:40:12 -06: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 05:21:39 +00:00
if (TR.isUsable()) {
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
QualType ReductionType = Actions.OpenMP().ActOnOpenMPDeclareReductionType(
Range.getBegin(), TR);
[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 05:21:39 +00:00
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();
}
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
DeclGroupPtrTy DRD =
Actions.OpenMP().ActOnOpenMPDeclareReductionDirectiveStart(
getCurScope(), Actions.getCurLexicalContext(), Name, ReductionTypes,
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 05:21:39 +00:00
// 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-23 19:53:05 +00: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 05:21:39 +00: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 15:43:06 +00: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 05:21:39 +00:00
Scope::OpenMPDirectiveScope);
// Parse <combiner> expression.
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
Actions.OpenMP().ActOnOpenMPDeclareReductionCombinerStart(getCurScope(), D);
[OPENMP]Allow comma in combiner expression. Use ParseExpression() instead of ParseAssignmentExpression() to allow commas in combiner expressions.
2020-01-08 09:39:44 -05:00
ExprResult CombinerResult = Actions.ActOnFinishFullExpr(
ParseExpression().get(), D->getLocation(), /*DiscardedValue*/ false);
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
Actions.OpenMP().ActOnOpenMPDeclareReductionCombinerEnd(
D, CombinerResult.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 05:21:39 +00:00
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-23 19:53:05 +00: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 05:21:39 +00:00
ConsumeToken();
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-23 19:53:05 +00: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 05:21:39 +00: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 15:43:06 +00: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 05:21:39 +00: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 14:49:58 +00:00
VarDecl *OmpPrivParm =
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
Actions.OpenMP().ActOnOpenMPDeclareReductionInitializerStart(
getCurScope(), D);
[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 14:49:58 +00:00
// 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-12 11:19:26 -05: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 14:49:58 +00: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-04 16:58:14 +00: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 14:49:58 +00:00
}
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
Actions.OpenMP().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 14:49:58 +00: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 05:21:39 +00: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();
}
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
return Actions.OpenMP().ActOnOpenMPDeclareReductionDirectiveEnd(
getCurScope(), DRD, IsCorrect);
[OPENMP] Added initial support for 'omp parallel for'. llvm-svn: 212453
2014-07-07 13:01:15 +00: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 14:49:58 +00: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 12:00:54 +01:00
cutOffParsing();
[clang] Introduce `SemaCodeCompletion` (#92311) This patch continues previous efforts to split `Sema` up, this time covering code completion. Context can be found in #84184. Dropping `Code` prefix from function names in `SemaCodeCompletion` would make sense, but I think this PR has enough changes already. As usual, formatting changes are done as a separate commit. Hopefully this helps with the review.
2024-05-17 20:55:37 +04:00
Actions.CodeCompletion().CodeCompleteInitializer(getCurScope(),
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 14:49:58 +00:00
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-12 11:19:26 -05: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-02 15:49:08 -05: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 14:49:58 +00: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;
[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 13:08:03 +00: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 11:01:50 +00:00
auto RunSignatureHelp = [this, OmpPrivParm, LParLoc, &Exprs]() {
[clang] Introduce `SemaCodeCompletion` (#92311) This patch continues previous efforts to split `Sema` up, this time covering code completion. Context can be found in #84184. Dropping `Code` prefix from function names in `SemaCodeCompletion` would make sense, but I think this PR has enough changes already. As usual, formatting changes are done as a separate commit. Hopefully this helps with the review.
2024-05-17 20:55:37 +04:00
QualType PreferredType =
Actions.CodeCompletion().ProduceConstructorSignatureHelp(
OmpPrivParm->getType()->getCanonicalTypeInternal(),
OmpPrivParm->getLocation(), Exprs, LParLoc, /*Braced=*/false);
[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 11:01:50 +00:00
CalledSignatureHelp = true;
return PreferredType;
};
[clang][Parse][NFC] Remove unused CommaLocs parameters
2022-11-17 15:49:30 +01:00
if (ParseExpressionList(Exprs, [&] {
[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 11:01:50 +00:00
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 14:49:58 +00: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-06 19:35:42 +00: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 14:49:58 +00:00
[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-06 19:35:42 +00: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 14:49:58 +00: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-01 20:25:04 +00: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-04 22:00:49 -06: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-01 20:25:04 +00: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())
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
MapperType = Actions.OpenMP().ActOnOpenMPDeclareMapperType(Range.getBegin(),
ParsedType);
[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-01 20:25:04 +00:00
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);
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
Actions.OpenMP().StartOpenMPDSABlock(OMPD_declare_mapper, DirName,
getCurScope(), Loc);
[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-01 20:25:04 +00:00
// Add the mapper variable declaration.
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
ExprResult MapperVarRef =
Actions.OpenMP().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-01 20:25:04 +00: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));
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
Actions.OpenMP().StartOpenMPClause(CKind);
[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-01 20:25:04 +00:00
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-26 17:42:31 -04: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-01 20:25:04 +00:00
if (Clause)
Clauses.push_back(Clause);
else
IsCorrect = false;
// Skip ',' if any.
if (Tok.is(tok::comma))
ConsumeToken();
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
Actions.OpenMP().EndOpenMPClause();
[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-01 20:25:04 +00:00
}
if (Clauses.empty()) {
Diag(Tok, diag::err_omp_expected_clause)
<< getOpenMPDirectiveName(OMPD_declare_mapper);
IsCorrect = false;
}
// Exit scope.
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
Actions.OpenMP().EndOpenMPDSABlock(nullptr);
[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-01 20:25:04 +00:00
OMPDirectiveScope.Exit();
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
DeclGroupPtrTy DG = Actions.OpenMP().ActOnOpenMPDeclareMapperDirective(
[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-26 17:42:31 -04:00
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-01 20:25:04 +00: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-26 17:42:31 -04: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-01 20:25:04 +00: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-10 23:40:12 -06:00
DeclaratorContext Context = DeclaratorContext::Prototype;
[clang] Reject non-declaration C++11 attributes on declarations For backwards compatiblity, we emit only a warning instead of an error if the attribute is one of the existing type attributes that we have historically allowed to "slide" to the `DeclSpec` just as if it had been specified in GNU syntax. (We will call these "legacy type attributes" below.) The high-level changes that achieve this are: - We introduce a new field `Declarator::DeclarationAttrs` (with appropriate accessors) to store C++11 attributes occurring in the attribute-specifier-seq at the beginning of a simple-declaration (and other similar declarations). Previously, these attributes were placed on the `DeclSpec`, which made it impossible to reconstruct later on whether the attributes had in fact been placed on the decl-specifier-seq or ahead of the declaration. - In the parser, we propgate declaration attributes and decl-specifier-seq attributes separately until we can place them in `Declarator::DeclarationAttrs` or `DeclSpec::Attrs`, respectively. - In `ProcessDeclAttributes()`, in addition to processing declarator attributes, we now also process the attributes from `Declarator::DeclarationAttrs` (except if they are legacy type attributes). - In `ConvertDeclSpecToType()`, in addition to processing `DeclSpec` attributes, we also process any legacy type attributes that occur in `Declarator::DeclarationAttrs` (and emit a warning). - We make `ProcessDeclAttribute` emit an error if it sees any non-declaration attributes in C++11 syntax, except in the following cases: - If it is being called for attributes on a `DeclSpec` or `DeclaratorChunk` - If the attribute is a legacy type attribute (in which case we only emit a warning) The standard justifies treating attributes at the beginning of a simple-declaration and attributes after a declarator-id the same. Here are some relevant parts of the standard: - The attribute-specifier-seq at the beginning of a simple-declaration "appertains to each of the entities declared by the declarators of the init-declarator-list" (https://eel.is/c++draft/dcl.dcl#dcl.pre-3) - "In the declaration for an entity, attributes appertaining to that entity can appear at the start of the declaration and after the declarator-id for that declaration." (https://eel.is/c++draft/dcl.dcl#dcl.pre-note-2) - "The optional attribute-specifier-seq following a declarator-id appertains to the entity that is declared." (https://eel.is/c++draft/dcl.dcl#dcl.meaning.general-1) The standard contains similar wording to that for a simple-declaration in other similar types of declarations, for example: - "The optional attribute-specifier-seq in a parameter-declaration appertains to the parameter." (https://eel.is/c++draft/dcl.fct#3) - "The optional attribute-specifier-seq in an exception-declaration appertains to the parameter of the catch clause" (https://eel.is/c++draft/except.pre#1) The new behavior is tested both on the newly added type attribute `annotate_type`, for which we emit errors, and for the legacy type attribute `address_space` (chosen somewhat randomly from the various legacy type attributes), for which we emit warnings. Depends On D111548 Reviewed By: aaron.ballman, rsmith Differential Revision: https://reviews.llvm.org/D126061
2022-06-15 08:07:23 +02:00
Declarator DeclaratorInfo(DS, ParsedAttributesView::none(), Context);
[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-01 20:25:04 +00:00
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();
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
return Actions.OpenMP().ActOnOpenMPDeclareMapperVarDecl(getCurScope(),
DeclaratorInfo);
[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-01 20:25:04 +00: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 12:45:37 +00: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-16 16:55:56 -07: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 12:45:37 +00: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-16 16:55:56 -07: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 12:45:37 +00: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 10:15:27 +00: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 12:45:37 +00: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-16 16:55:56 -07: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 12:45:37 +00: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-16 16:55:56 -07: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 12:45:37 +00: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-16 16:55:56 -07: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 12:45:37 +00: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-16 16:55:56 -07: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 12:45:37 +00: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 09:35:56 +00: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 11:02:11 +00: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 09:35:56 +00: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();
[clang] Use StringRef::operator== instead of StringRef::equals (NFC) (#91844) I'm planning to remove StringRef::equals in favor of StringRef::operator==. - StringRef::operator==/!= outnumber StringRef::equals by a factor of 24 under clang/ in terms of their usage. - The elimination of StringRef::equals brings StringRef closer to std::string_view, which has operator== but not equals. - S == "foo" is more readable than S.equals("foo"), especially for !Long.Expression.equals("str") vs Long.Expression != "str".
2024-05-11 11:38:52 -07:00
} else if (ClauseName == "simdlen") {
[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 09:35:56 +00:00
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 11:02:11 +00:00
if (CKind == OMPC_uniform || CKind == OMPC_aligned ||
CKind == OMPC_linear) {
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
SemaOpenMP::OpenMPVarListDataTy Data;
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-23 19:53:05 +00: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-24 16:02:58 -05: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 09:35:56 +00: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-24 16:02:58 -05: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 11:02:11 +00: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-24 16:02:58 -05: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 09:35:56 +00: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-23 19:53:05 +00: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-01 15:06:38 -04:00
Alignments.append(Aligneds.size() - Alignments.size(),
Data.DepModOrTailExpr);
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-23 19:53:05 +00: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-24 16:02:58 -05:00
assert(0 <= Data.ExtraModifier &&
Data.ExtraModifier <= OMPC_LINEAR_unknown &&
"Unexpected linear modifier.");
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
if (P.getActions().OpenMP().CheckOpenMPLinearModifier(
[OPENMP50]Basic support for conditional lastprivate. Added parsing/sema checks for conditional lastprivates.
2019-12-20 11:04:57 -05:00
static_cast<OpenMPLinearClauseKind>(Data.ExtraModifier),
[OPENMP50]Add 'default' modifier in reduction clauses. Added full support for 'default' modifier in the reduction clauses.
2020-03-23 17:30:38 -04:00
Data.ExtraModifierLoc))
[OPENMP50]Basic support for conditional lastprivate. Added parsing/sema checks for conditional lastprivates.
2019-12-20 11:04:57 -05: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 11:02:11 +00:00
LinModifiers.append(Linears.size() - LinModifiers.size(),
[OPENMP50]Basic support for conditional lastprivate. Added parsing/sema checks for conditional lastprivates.
2019-12-20 11:04:57 -05: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-01 15:06:38 -04: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 11:02:11 +00: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 09:35:56 +00: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 12:45:37 +00: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 09:32:05 +00: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 12:45:37 +00: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-13 20:18:17 +00: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 12:45:37 +00: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 05:28:34 +00: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 09:35:56 +00: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 11:02:11 +00: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-21 13:48:56 -06: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 12:45:37 +00: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-18 19:21:48 +00:00
SourceLocation EndLoc = ConsumeAnnotationToken();
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-23 19:53:05 +00:00
if (IsError)
return Ptr;
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
return Actions.OpenMP().ActOnOpenMPDeclareSimdDirective(
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-23 19:53:05 +00:00
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 10:12:15 +00: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-19 20:42:12 -06: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-16 11:28:31 -05: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-19 20:42:12 -06: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-29 18:44:28 -05: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-19 20:42:12 -06:00
TIProperty.Kind = TraitProperty::invalid;
SourceLocation NameLoc = Tok.getLocation();
[OpenMP]Initial parsing/sema support for target_device selector set (#118471) This patch adds initial support for target_device selector set - Section 9.2 (Spec 6.0)
2025-02-05 19:24:24 +05:30
StringRef Name;
if (Selector == llvm::omp::TraitSelector::target_device_device_num) {
Name = "number";
TIProperty.Kind = getOpenMPContextTraitPropertyKind(Set, Selector, Name);
ExprResult DeviceNumExprResult = ParseExpression();
if (DeviceNumExprResult.isUsable()) {
Expr *DeviceNumExpr = DeviceNumExprResult.get();
Actions.OpenMP().ActOnOpenMPDeviceNum(DeviceNumExpr);
}
return;
}
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-19 20:42:12 -06: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 01:08:03 -05: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-19 20:42:12 -06: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;
}
[OpenMP]Initial parsing/sema support for target_device selector set (#118471) This patch adds initial support for target_device selector set - Section 9.2 (Spec 6.0)
2025-02-05 19:24:24 +05:30
TraitSelector SelectorForName =
getOpenMPContextTraitSelectorKind(Name, SetForName);
[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-19 20:42:12 -06:00
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,
[OpenMP]Initial parsing/sema support for target_device selector set (#118471) This patch adds initial support for target_device selector set - Section 9.2 (Spec 6.0)
2025-02-05 19:24:24 +05:30
TraitSet::device, TraitSet::target_device}) {
[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-19 20:42:12 -06:00
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 01:08:03 -05: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-19 20:42:12 -06: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-03 11:29:53 -05: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-12 16:49:10 -05: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-05-31 11:40:09 -05:00
if (TIProperty.Kind ==
TraitProperty::implementation_extension_allow_templates)
return true;
[OpenMP] Add variant extension that applies to declarations This patch adds a new extension to the `omp begin / end declare variant` support that causes it to apply to function declarations as well. This is explicitly not done in the standard, but can be useful in some situations so we should provide it as an extension. This will allow us to uniquely bind and overload existing definitions with a simple declaration using variants. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D124624
2022-06-29 14:53:45 -04:00
if (TIProperty.Kind ==
TraitProperty::implementation_extension_bind_to_declaration)
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-03 11:29:53 -05: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 01:08:03 -05: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-03 11:29:53 -05: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-03 12:35:30 -07: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-19 20:42:12 -06: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-03 12:35:30 -07: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-19 20:42:12 -06: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-03 11:29:53 -05: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-19 20:42:12 -06: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-03 11:29:53 -05: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-19 20:42:12 -06: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 01:08:03 -05: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-19 20:42:12 -06: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 01:08:03 -05: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-19 20:42:12 -06: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-29 18:44:28 -05: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-19 20:42:12 -06: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-29 18:44:28 -05: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-19 20:42:12 -06:00
if (Name.empty()) {
Diag(Tok.getLocation(), diag::note_omp_declare_variant_ctx_options)
<< CONTEXT_SELECTOR_LVL << listOpenMPContextTraitSelectors(Set);
return;
}
[OpenMP]Initial parsing/sema support for target_device selector set (#118471) This patch adds initial support for target_device selector set - Section 9.2 (Spec 6.0)
2025-02-05 19:24:24 +05:30
TISelector.Kind = getOpenMPContextTraitSelectorKind(Name, 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-19 20:42:12 -06:00
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,
[OpenMP]Initial parsing/sema support for target_device selector set (#118471) This patch adds initial support for target_device selector set - Section 9.2 (Spec 6.0)
2025-02-05 19:24:24 +05:30
TraitSet::device, TraitSet::target_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 01:08:03 -05: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-19 20:42:12 -06: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-02 18:19:02 +00: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-19 20:42:12 -06: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-02 18:19:02 +00:00
StringRef SelectorName =
P.getPreprocessor().getSpelling(P.getCurToken(), Buffer);
[clang] Use StringRef::operator== instead of StringRef::equals (NFC) (#91844) I'm planning to remove StringRef::equals in favor of StringRef::operator==. - StringRef::operator==/!= outnumber StringRef::equals by a factor of 24 under clang/ in terms of their usage. - The elimination of StringRef::equals brings StringRef closer to std::string_view, which has operator== but not equals. - S == "foo" is more readable than S.equals("foo"), especially for !Long.Expression.equals("str") vs Long.Expression != "str".
2024-05-11 11:38:52 -07:00
if (SelectorName != "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-02 18:19:02 +00: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-19 20:42:12 -06: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-02 18:19:02 +00: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-19 20:42:12 -06: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-03 12:35:30 -07: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-19 20:42:12 -06: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 15:58:45 +00: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-19 20:42:12 -06: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 15:58:45 +00: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-19 20:42:12 -06: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-25 19:43:37 +00: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-19 20:42:12 -06: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 01:08:03 -05: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-25 19:43:37 +00: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-19 20:42:12 -06: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 01:08:03 -05: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-19 20:42:12 -06: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-20 19:50:47 -06: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-19 20:42:12 -06: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-20 19:50:47 -06: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-19 20:42:12 -06: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-25 19:43:37 +00: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-03 12:35:30 -07: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-19 20:42:12 -06: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-29 18:44:28 -05: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-19 20:42:12 -06: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-05 15:13:30 -05: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-19 20:42:12 -06: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-05 15:13:30 -05: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-19 20:42:12 -06:00
// It follows diagnosis and helping notes.
Diag(NameLoc, diag::warn_omp_declare_variant_ctx_not_a_set) << Name;
[OpenMP]Initial parsing/sema support for target_device selector set (#118471) This patch adds initial support for target_device selector set - Section 9.2 (Spec 6.0)
2025-02-05 19:24:24 +05:30
TraitSelector SelectorForName =
getOpenMPContextTraitSelectorKind(Name, TISet.Kind);
[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-19 20:42:12 -06:00
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,
[OpenMP]Initial parsing/sema support for target_device selector set (#118471) This patch adds initial support for target_device selector set - Section 9.2 (Spec 6.0)
2025-02-05 19:24:24 +05:30
TraitSet::device, TraitSet::target_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 01:08:03 -05: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-19 20:42:12 -06: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-29 18:44:28 -05: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-19 20:42:12 -06: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-05 15:13:30 -05: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-19 20:42:12 -06: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-05 15:13:30 -05: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-19 20:42:12 -06: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-05 15:13:30 -05: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-19 20:42:12 -06: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-03 12:35:30 -07: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-19 20:42:12 -06: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-05 15:13:30 -05: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-19 20:42:12 -06: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-29 18:44:28 -05: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-19 20:42:12 -06: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-18 16:24:31 +00: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-03 12:35:30 -07: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-19 20:42:12 -06: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-13 20:18:17 +00: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-18 16:24:31 +00: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-13 20:18:17 +00: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-10 16:12:53 -05: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-13 20:18:17 +00: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-18 16:24:31 +00: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-13 20:18:17 +00:00
}
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
OMPTraitInfo *ParentTI =
Actions.OpenMP().getOMPTraitInfoForSurroundingScope();
[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 01:05:51 -05:00
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-12 14:55:00 -07:00
SmallVector<Expr *, 6> AdjustNothing;
SmallVector<Expr *, 6> AdjustNeedDevicePtr;
[OpenMP][NFC] Use OMPInteropInfo in the OMPDeclareVariantAttr attribute In preparation for allowing the prefer_type list in the append_args clause, use the OMPInteropInfo in the attribute for 'declare variant'. This requires adding a new Argument kind to the attribute code. This change adds a specific attribute to pass an array of OMPInteropInfo. It implements new tablegen needed to handle the interop-type part of the structure. When prefer_type is added, more work will be needed to dump, instantiate, and serialize the PreferTypes field in OMPInteropInfo. Differential Revision: https://reviews.llvm.org/D132270
2022-08-19 16:44:55 -07:00
SmallVector<OMPInteropInfo, 3> AppendArgs;
[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-14 14:28:51 -07:00
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-12 14:55:00 -07: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-14 14:28:51 -07: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-12 14:55:00 -07:00
ConsumeToken();
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
SemaOpenMP::OpenMPVarListDataTy Data;
[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-12 14:55:00 -07:00
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-14 14:28:51 -07: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-12 14:55:00 -07: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-20 19:50:47 -06:00
[clang] Use std::optional instead of llvm::Optional (NFC) This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to remove #include "llvm/ADT/Optional.h". This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2023-01-14 12:31:01 -08:00
std::optional<std::pair<FunctionDecl *, Expr *>> DeclVarData =
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
Actions.OpenMP().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-14 14:28:51 -07: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-20 19:50:47 -06:00
SourceRange(Loc, Tok.getLocation()));
if (DeclVarData && !TI.Sets.empty())
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
Actions.OpenMP().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-12 14:55:00 -07: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-14 14:28:51 -07: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-20 19:50:47 -06: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-14 14:28:51 -07:00
bool Parser::parseOpenMPAppendArgs(
[OpenMP][NFC] Use OMPInteropInfo in the OMPDeclareVariantAttr attribute In preparation for allowing the prefer_type list in the append_args clause, use the OMPInteropInfo in the attribute for 'declare variant'. This requires adding a new Argument kind to the attribute code. This change adds a specific attribute to pass an array of OMPInteropInfo. It implements new tablegen needed to handle the interop-type part of the structure. When prefer_type is added, more work will be needed to dump, instantiate, and serialize the PreferTypes field in OMPInteropInfo. Differential Revision: https://reviews.llvm.org/D132270
2022-08-19 16:44:55 -07:00
SmallVectorImpl<OMPInteropInfo> &InteropInfos) {
[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-14 14:28:51 -07:00
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;
[OpenMP][NFC] Refactor code for interop parts of 'init' and 'append_args' clauses The 'init' clause allows an interop-modifier of prefer_type(list) and and interop-types 'target' and 'targetsync'. The 'append_args' clause uses an append-op that also includes interop-types ('target' and 'targetsync') and will allow a prefer_type list in the next OpenMP version. This change adds a helper struct OMPInteropInfo and uses it in the parsing of both the 'init' and 'append_args' clauses. One OMPInteropInfo object represents the info in a single 'init' clause. Since 'append_args' allows a variable number of interop items it will require an array of OMPInteropInfo objects once that is supported. Differential Revision: https://reviews.llvm.org/D132171
2022-08-18 11:54:52 -07:00
OMPInteropInfo InteropInfo;
[OpenMP][NFC] Use OMPInteropInfo in the OMPDeclareVariantAttr attribute In preparation for allowing the prefer_type list in the append_args clause, use the OMPInteropInfo in the attribute for 'declare variant'. This requires adding a new Argument kind to the attribute code. This change adds a specific attribute to pass an array of OMPInteropInfo. It implements new tablegen needed to handle the interop-type part of the structure. When prefer_type is added, more work will be needed to dump, instantiate, and serialize the PreferTypes field in OMPInteropInfo. Differential Revision: https://reviews.llvm.org/D132270
2022-08-19 16:44:55 -07:00
if (ParseOMPInteropInfo(InteropInfo, OMPC_append_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-14 14:28:51 -07:00
HasError = true;
[OpenMP][NFC] Use OMPInteropInfo in the OMPDeclareVariantAttr attribute In preparation for allowing the prefer_type list in the append_args clause, use the OMPInteropInfo in the attribute for 'declare variant'. This requires adding a new Argument kind to the attribute code. This change adds a specific attribute to pass an array of OMPInteropInfo. It implements new tablegen needed to handle the interop-type part of the structure. When prefer_type is added, more work will be needed to dump, instantiate, and serialize the PreferTypes field in OMPInteropInfo. Differential Revision: https://reviews.llvm.org/D132270
2022-08-19 16:44:55 -07:00
else
InteropInfos.push_back(InteropInfo);
[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-14 14:28:51 -07:00
IT.consumeClose();
if (Tok.is(tok::comma))
ConsumeToken();
}
[OpenMP][NFC] Use OMPInteropInfo in the OMPDeclareVariantAttr attribute In preparation for allowing the prefer_type list in the append_args clause, use the OMPInteropInfo in the attribute for 'declare variant'. This requires adding a new Argument kind to the attribute code. This change adds a specific attribute to pass an array of OMPInteropInfo. It implements new tablegen needed to handle the interop-type part of the structure. When prefer_type is added, more work will be needed to dump, instantiate, and serialize the PreferTypes field in OMPInteropInfo. Differential Revision: https://reviews.llvm.org/D132270
2022-08-19 16:44:55 -07:00
if (!HasError && InteropInfos.empty()) {
[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-14 14:28:51 -07:00
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-20 19:50:47 -06: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 01:05:51 -05: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-18 16:24:31 +00: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-23 18:13:31 +00: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-18 16:24:31 +00: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-12 14:55:00 -07: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-20 19:50:47 -06: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-13 20:18:17 +00: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-18 16:24:31 +00: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-23 18:13:31 +00: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-12 14:55:00 -07: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-20 19:50:47 -06: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-18 16:24:31 +00:00
// Parse inner context selectors.
[FIX] Remove pointer in attribute to eliminate leaks (see D71830)
2020-02-15 18:07:42 -06: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-19 20:42:12 -06: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 01:05:51 -05: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-11 23:47:10 -06: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 01:05:51 -05: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-11 23:47:19 -06: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 01:05:51 -05: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-20 19:50:47 -06: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-13 20:18:17 +00:00
}
[OPENMP]Initial support for at clause Error directive is allowed in both declared and executable contexts. The function ActOnOpenMPAtClause is called in both places during the parsers. Adding a param "bool InExContext" to identify context which is used to emit error massage. Differential Revision: https://reviews.llvm.org/D137851
2022-11-10 18:12:35 -08:00
/// <clause> [clause[ [,] clause] ... ]
///
/// clauses: for error directive
/// 'at' '(' compilation | execution ')'
/// 'severity' '(' fatal | warning ')'
/// 'message' '(' msg-string ')'
/// ....
void Parser::ParseOpenMPClauses(OpenMPDirectiveKind DKind,
SmallVectorImpl<OMPClause *> &Clauses,
SourceLocation Loc) {
[clang][OpenMP] Simplify check for repeated clauses (#93611) The `FirstClauses` is a vector of pointer-bool pairs, and the pointer part of the pair is never used. Replace the vector with std::bitset, and rename it to `SeenClauses` to make the purpose of it a bit clearer.
2024-05-30 14:49:13 -05:00
std::bitset<llvm::omp::Clause_enumSize + 1> SeenClauses;
[OPENMP]Initial support for at clause Error directive is allowed in both declared and executable contexts. The function ActOnOpenMPAtClause is called in both places during the parsers. Adding a param "bool InExContext" to identify context which is used to emit error massage. Differential Revision: https://reviews.llvm.org/D137851
2022-11-10 18:12:35 -08:00
while (Tok.isNot(tok::annot_pragma_openmp_end)) {
OpenMPClauseKind CKind = Tok.isAnnotation()
? OMPC_unknown
: getOpenMPClauseKind(PP.getSpelling(Tok));
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
Actions.OpenMP().StartOpenMPClause(CKind);
[clang][OpenMP] Simplify check for repeated clauses (#93611) The `FirstClauses` is a vector of pointer-bool pairs, and the pointer part of the pair is never used. Replace the vector with std::bitset, and rename it to `SeenClauses` to make the purpose of it a bit clearer.
2024-05-30 14:49:13 -05:00
OMPClause *Clause =
ParseOpenMPClause(DKind, CKind, !SeenClauses[unsigned(CKind)]);
[OPENMP]Initial support for at clause Error directive is allowed in both declared and executable contexts. The function ActOnOpenMPAtClause is called in both places during the parsers. Adding a param "bool InExContext" to identify context which is used to emit error massage. Differential Revision: https://reviews.llvm.org/D137851
2022-11-10 18:12:35 -08:00
SkipUntil(tok::comma, tok::identifier, tok::annot_pragma_openmp_end,
StopBeforeMatch);
[clang][OpenMP] Simplify check for repeated clauses (#93611) The `FirstClauses` is a vector of pointer-bool pairs, and the pointer part of the pair is never used. Replace the vector with std::bitset, and rename it to `SeenClauses` to make the purpose of it a bit clearer.
2024-05-30 14:49:13 -05:00
SeenClauses[unsigned(CKind)] = true;
[OPENMP]Initial support for at clause Error directive is allowed in both declared and executable contexts. The function ActOnOpenMPAtClause is called in both places during the parsers. Adding a param "bool InExContext" to identify context which is used to emit error massage. Differential Revision: https://reviews.llvm.org/D137851
2022-11-10 18:12:35 -08:00
if (Clause != nullptr)
Clauses.push_back(Clause);
if (Tok.is(tok::annot_pragma_openmp_end)) {
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
Actions.OpenMP().EndOpenMPClause();
[OPENMP]Initial support for at clause Error directive is allowed in both declared and executable contexts. The function ActOnOpenMPAtClause is called in both places during the parsers. Adding a param "bool InExContext" to identify context which is used to emit error massage. Differential Revision: https://reviews.llvm.org/D137851
2022-11-10 18:12:35 -08:00
break;
}
// Skip ',' if any.
if (Tok.is(tok::comma))
ConsumeToken();
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
Actions.OpenMP().EndOpenMPClause();
[OPENMP]Initial support for at clause Error directive is allowed in both declared and executable contexts. The function ActOnOpenMPAtClause is called in both places during the parsers. Adding a param "bool InExContext" to identify context which is used to emit error massage. Differential Revision: https://reviews.llvm.org/D137851
2022-11-10 18:12:35 -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-23 11:48:59 -06: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'
[clang][OpenMP] New OpenMP 6.0 assumption clause, 'no_openmp_constructs' (#125933) Add initial parsing/sema support for new assumption clause so clause can be specified. For now, it's ignored, just like the others. Added support for 'no_openmp_construct' to release notes. Testing - Updated appropriate LIT tests. - Testing: check-all
2025-02-06 12:41:10 -08:00
/// 'no_openmp_constructs' (OpenMP 6.0)
[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-23 11:48:59 -06:00
/// '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-13 15:35:58 -05: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-23 11:48:59 -06: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-13 15:35:58 -05: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-23 11:48:59 -06: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-13 15:35:58 -05: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-23 11:48:59 -06:00
Assumptions.push_back(Assumption);
}
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
Actions.OpenMP().ActOnOpenMPAssumesDirective(Loc, DKind, Assumptions,
SkippedClauses);
[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-23 11:48:59 -06:00
}
void Parser::ParseOpenMPEndAssumesDirective(SourceLocation Loc) {
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
if (Actions.OpenMP().isInOpenMPAssumeScope())
Actions.OpenMP().ActOnOpenMPEndAssumesDirective();
[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-23 11:48:59 -06:00
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-23 16:11:14 +00:00
/// Parsing of simple OpenMP clauses like 'default' or 'proc_bind'.
///
/// default-clause:
[Clang][[OpenMP5.1] Initial parser/sema for default(private) clause This implements the default(private) clause as defined in OMP5.1 Differential Revision: https://reviews.llvm.org/D125912
2022-05-17 14:17:32 -07:00
/// 'default' '(' 'none' | 'shared' | 'private' | '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-23 16:11:14 +00: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-29 18:44:28 -05: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-23 16:11:14 +00:00
} // anonymous namespace
[clang] Use std::optional instead of llvm::Optional (NFC) This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to remove #include "llvm/ADT/Optional.h". This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2023-01-14 12:31:01 -08:00
static std::optional<SimpleClauseData>
[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-23 16:11:14 +00:00
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-30 19:58:40 -05:00
getOpenMPClauseName(Kind).data()))
[clang] Use std::nullopt instead of None (NFC) This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of manual work required in migrating from Optional to std::optional. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-03 11:54:46 -08:00
return std::nullopt;
[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-23 16:11:14 +00:00
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 10:14:00 -04: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-08-31 15:17:07 -04: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-23 16:11:14 +00: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 00:57:28 -05:00
void Parser::ParseOMPDeclareTargetClauses(
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
SemaOpenMP::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-23 16:11:14 +00:00
SourceLocation DeviceTypeLoc;
[clang][OpenMP5.1] Initial parsing/sema for 'indirect' clause Differential Revision: https://reviews.llvm.org/D116764
2022-01-10 16:20:02 -08:00
bool RequiresToOrLinkOrIndirectClause = false;
bool HasToOrLinkOrIndirectClause = 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-21 20:15:57 +00: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 00:57:28 -05:00
bool HasIdentifier = Tok.is(tok::identifier);
if (HasIdentifier) {
// If we see any clause we need a to or link clause.
[clang][OpenMP5.1] Initial parsing/sema for 'indirect' clause Differential Revision: https://reviews.llvm.org/D116764
2022-01-10 16:20:02 -08:00
RequiresToOrLinkOrIndirectClause = 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-21 20:15:57 +00: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-23 16:11:14 +00: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 00:57:28 -05:00
[clang][OpenMP5.1] Initial parsing/sema for 'indirect' clause Differential Revision: https://reviews.llvm.org/D116764
2022-01-10 16:20:02 -08:00
bool IsIndirectClause = getLangOpts().OpenMP >= 51 &&
getOpenMPClauseKind(ClauseName) == OMPC_indirect;
[clang] Don't use Optional::hasValue (NFC)
2022-06-20 10:51:34 -07:00
if (DTCI.Indirect && IsIndirectClause) {
[clang][OpenMP5.1] Initial parsing/sema for 'indirect' clause Differential Revision: https://reviews.llvm.org/D116764
2022-01-10 16:20:02 -08:00
Diag(Tok, diag::err_omp_more_one_clause)
<< getOpenMPDirectiveName(OMPD_declare_target)
<< getOpenMPClauseName(OMPC_indirect) << 0;
break;
}
Fix declare target implementation to support enter.
2022-11-16 17:23:48 -06:00
bool IsToEnterOrLinkClause =
[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 00:57:28 -05:00
OMPDeclareTargetDeclAttr::ConvertStrToMapTypeTy(ClauseName, MT);
Fix declare target implementation to support enter.
2022-11-16 17:23:48 -06:00
assert((!IsDeviceTypeClause || !IsToEnterOrLinkClause) &&
"Cannot be both!");
// Starting with OpenMP 5.2 the `to` clause has been replaced by the
// `enter` clause.
if (getLangOpts().OpenMP >= 52 && ClauseName == "to") {
Diag(Tok, diag::err_omp_declare_target_unexpected_to_clause);
break;
}
if (getLangOpts().OpenMP <= 51 && ClauseName == "enter") {
Diag(Tok, diag::err_omp_declare_target_unexpected_enter_clause);
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 00:57:28 -05:00
[clang][OpenMP5.1] Initial parsing/sema for 'indirect' clause Differential Revision: https://reviews.llvm.org/D116764
2022-01-10 16:20:02 -08:00
if (!IsDeviceTypeClause && !IsIndirectClause &&
DTCI.Kind == OMPD_begin_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 00:57:28 -05:00
Diag(Tok, diag::err_omp_declare_target_unexpected_clause)
[clang][OpenMP5.1] Initial parsing/sema for 'indirect' clause Differential Revision: https://reviews.llvm.org/D116764
2022-01-10 16:20:02 -08:00
<< ClauseName << (getLangOpts().OpenMP >= 51 ? 3 : 0);
[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 00:57:28 -05:00
break;
}
Fix declare target implementation to support enter.
2022-11-16 17:23:48 -06:00
if (!IsDeviceTypeClause && !IsToEnterOrLinkClause && !IsIndirectClause) {
Diag(Tok, getLangOpts().OpenMP >= 52
? diag::err_omp_declare_target_unexpected_clause_52
: diag::err_omp_declare_target_unexpected_clause)
[clang][OpenMP5.1] Initial parsing/sema for 'indirect' clause Differential Revision: https://reviews.llvm.org/D116764
2022-01-10 16:20:02 -08:00
<< ClauseName
Fix declare target implementation to support enter.
2022-11-16 17:23:48 -06:00
<< (getLangOpts().OpenMP >= 51
? 4
: 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-21 20:15:57 +00: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 00:57:28 -05:00
Fix declare target implementation to support enter.
2022-11-16 17:23:48 -06:00
if (IsToEnterOrLinkClause || IsIndirectClause)
[clang][OpenMP5.1] Initial parsing/sema for 'indirect' clause Differential Revision: https://reviews.llvm.org/D116764
2022-01-10 16:20:02 -08:00
HasToOrLinkOrIndirectClause = true;
[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 00:57:28 -05:00
[clang][OpenMP5.1] Initial parsing/sema for 'indirect' clause Differential Revision: https://reviews.llvm.org/D116764
2022-01-10 16:20:02 -08:00
if (IsIndirectClause) {
if (!ParseOpenMPIndirectClause(DTCI, /*ParseOnly*/ false))
break;
continue;
}
[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-23 16:11:14 +00:00
// Parse 'device_type' clause and go to next clause if any.
if (IsDeviceTypeClause) {
[clang] Use std::optional instead of llvm::Optional (NFC) This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to remove #include "llvm/ADT/Optional.h". This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2023-01-14 12:31:01 -08:00
std::optional<SimpleClauseData> DevTypeData =
[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-23 16:11:14 +00:00
parseOpenMPSimpleClause(*this, OMPC_device_type);
[clang] Don't use Optional::hasValue (NFC) This patch replaces Optional::hasValue with the implicit cast to bool in conditionals only.
2022-06-25 22:26:24 -07:00
if (DevTypeData) {
[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-23 16:11:14 +00:00
if (DeviceTypeLoc.isValid()) {
// We already saw another device_type clause, diagnose it.
llvm::Optional::value => operator*/operator-> std::optional::value() has undesired exception checking semantics and is unavailable in older Xcode (see _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS). The call sites block std::optional migration. This makes `ninja clang` work in the absence of llvm::Optional::value.
2022-12-17 06:37:59 +00:00
Diag(DevTypeData->Loc,
Revert "Don't use Optional::hasValue (NFC)" This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.
2022-06-25 11:56:50 -07:00
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 00:57:28 -05: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-23 16:11:14 +00:00
}
llvm::Optional::value => operator*/operator-> std::optional::value() has undesired exception checking semantics and is unavailable in older Xcode (see _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS). The call sites block std::optional migration. This makes `ninja clang` work in the absence of llvm::Optional::value.
2022-12-17 06:37:59 +00:00
switch (static_cast<OpenMPDeviceType>(DevTypeData->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-23 16:11:14 +00: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 00:57:28 -05: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-23 16:11:14 +00: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 00:57:28 -05: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-23 16:11:14 +00: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 00:57:28 -05: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-23 16:11:14 +00:00
break;
case OMPC_DEVICE_TYPE_unknown:
llvm_unreachable("Unexpected device_type");
}
[clang] Don't use Optional::getValue (NFC)
2022-06-20 22:59:26 -07:00
DeviceTypeLoc = DevTypeData->Loc;
[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-23 16:11:14 +00:00
}
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-21 20:15:57 +00: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 00:57:28 -05:00
if (DTCI.Kind == OMPD_declare_target || HasIdentifier) {
auto &&Callback = [this, MT, &DTCI](CXXScopeSpec &SS,
DeclarationNameInfo NameInfo) {
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
NamedDecl *ND = Actions.OpenMP().lookupOpenMPDeclareTargetName(
getCurScope(), SS, NameInfo);
[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 00:57:28 -05:00
if (!ND)
return;
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
SemaOpenMP::DeclareTargetContextInfo::MapInfo MI{MT, NameInfo.getLoc()};
[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 00:57:28 -05:00
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,
Fix declare target implementation to support enter.
2022-11-16 17:23:48 -06:00
getLangOpts().OpenMP >= 52
? diag::err_omp_declare_target_wrong_clause_after_implicit_enter
: diag::err_omp_declare_target_wrong_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-21 20:15:57 +00: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 00:57:28 -05: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-21 20:15:57 +00: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 00:57:28 -05:00
[clang] Don't use Optional::hasValue (NFC)
2022-06-20 10:51:34 -07:00
if (DTCI.Indirect && DTCI.DT != OMPDeclareTargetDeclAttr::DT_Any)
[clang][OpenMP5.1] Initial parsing/sema for 'indirect' clause Differential Revision: https://reviews.llvm.org/D116764
2022-01-10 16:20:02 -08:00
Diag(DeviceTypeLoc, diag::err_omp_declare_target_indirect_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 00:57:28 -05:00
// For declare target require at least 'to' or 'link' to be present.
[clang][OpenMP5.1] Initial parsing/sema for 'indirect' clause Differential Revision: https://reviews.llvm.org/D116764
2022-01-10 16:20:02 -08:00
if (DTCI.Kind == OMPD_declare_target && RequiresToOrLinkOrIndirectClause &&
!HasToOrLinkOrIndirectClause)
Fix declare target implementation to support enter.
2022-11-16 17:23:48 -06:00
Diag(DTCI.Loc,
getLangOpts().OpenMP >= 52
? diag::err_omp_declare_target_missing_enter_or_link_clause
: diag::err_omp_declare_target_missing_to_or_link_clause)
[clang][OpenMP5.1] Initial parsing/sema for 'indirect' clause Differential Revision: https://reviews.llvm.org/D116764
2022-01-10 16:20:02 -08:00
<< (getLangOpts().OpenMP >= 51 ? 1 : 0);
[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 00:57:28 -05: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-21 20:15:57 +00: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-21 13:48:56 -06: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-20 19:50:47 -06: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-21 20:15:57 +00: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-20 19:50:47 -06: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 00:57:28 -05: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-20 19:50:47 -06: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 00:57:28 -05: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-20 19:50:47 -06: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-21 20:15:57 +00: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-20 19:50:47 -06: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-21 20:15:57 +00: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 01:00:01 +00:00
/// Parsing of declarative OpenMP directives.
OpenMP threadprivate with qualified names. llvm-svn: 181683
2013-05-13 04:18:18 +00: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 05:21:39 +00:00
/// annot_pragma_openmp_end
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 06:34:35 +00: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-07 17:54:44 +00: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-12 18:52:33 +00: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-07 17:54:44 +00: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 05:21:39 +00: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-01 20:25:04 +00: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 10:43:55 +00: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 04:28:39 +00: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-23 11:48:59 -06: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 10:43:55 +00:00
Parser::DeclGroupPtrTy Parser::ParseOpenMPDeclarativeDirectiveWithExtDecl(
[clang][parse] Move source range into ParsedAttibutesView Move the SourceRange from the old ParsedAttributesWithRange into ParsedAttributesView, so we have source range information available everywhere we use attributes. This also removes ParsedAttributesWithRange (replaced by simply using ParsedAttributes) and ParsedAttributesVieWithRange (replaced by using ParsedAttributesView). Differential Revision: https://reviews.llvm.org/D121201
2022-03-22 09:27:27 +01:00
AccessSpecifier &AS, ParsedAttributes &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 10:43:55 +00: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 06:51:19 -04: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-13 16:05:30 -05:00
ParsingOpenMPDirectiveRAII DirScope(*this);
Replaced bool parameters in SkipUntil function with single bit-based parameter. llvm-svn: 194994
2013-11-18 08:17:37 +00:00
ParenBraceBracketBalancer BalancerRAIIObj(*this);
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 06:34:35 +00: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-07 13:39:18 -05: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 06:51:19 -04: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-07 13:39:18 -05: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 04:18:18 +00: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 14:59:13 +00:00
case OMPD_threadprivate: {
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 06:34:35 +00: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-07 17:54:44 +00: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-21 13:48:56 -06:00
skipUntilPragmaOpenMPEnd(DKind);
OpenMP threadprivate with qualified names. llvm-svn: 181683
2013-05-13 04:18:18 +00: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-18 19:21:48 +00:00
ConsumeAnnotationToken();
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
return Actions.OpenMP().ActOnOpenMPThreadprivateDirective(
Loc, Helper.getIdentifiers());
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 06:34:35 +00: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 14:59:13 +00: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-07 17:54:44 +00: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-12 18:52:33 +00: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-07 17:54:44 +00:00
if (Tok.isNot(tok::annot_pragma_openmp_end)) {
[clang][OpenMP] Simplify check for repeated clauses (#93611) The `FirstClauses` is a vector of pointer-bool pairs, and the pointer part of the pair is never used. Replace the vector with std::bitset, and rename it to `SeenClauses` to make the purpose of it a bit clearer.
2024-05-30 14:49:13 -05:00
std::bitset<llvm::omp::Clause_enumSize + 1> SeenClauses;
[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-12 18:52:33 +00:00
while (Tok.isNot(tok::annot_pragma_openmp_end)) {
OpenMPClauseKind CKind =
Tok.isAnnotation() ? OMPC_unknown
: getOpenMPClauseKind(PP.getSpelling(Tok));
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
Actions.OpenMP().StartOpenMPClause(CKind);
[clang][OpenMP] Simplify check for repeated clauses (#93611) The `FirstClauses` is a vector of pointer-bool pairs, and the pointer part of the pair is never used. Replace the vector with std::bitset, and rename it to `SeenClauses` to make the purpose of it a bit clearer.
2024-05-30 14:49:13 -05:00
OMPClause *Clause = ParseOpenMPClause(OMPD_allocate, CKind,
!SeenClauses[unsigned(CKind)]);
[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-12 18:52:33 +00:00
SkipUntil(tok::comma, tok::identifier, tok::annot_pragma_openmp_end,
StopBeforeMatch);
[clang][OpenMP] Simplify check for repeated clauses (#93611) The `FirstClauses` is a vector of pointer-bool pairs, and the pointer part of the pair is never used. Replace the vector with std::bitset, and rename it to `SeenClauses` to make the purpose of it a bit clearer.
2024-05-30 14:49:13 -05:00
SeenClauses[unsigned(CKind)] = 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-12 18:52:33 +00:00
if (Clause != nullptr)
Clauses.push_back(Clause);
if (Tok.is(tok::annot_pragma_openmp_end)) {
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
Actions.OpenMP().EndOpenMPClause();
[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-12 18:52:33 +00:00
break;
}
// Skip ',' if any.
if (Tok.is(tok::comma))
ConsumeToken();
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
Actions.OpenMP().EndOpenMPClause();
[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-12 18:52:33 +00:00
}
[OpenMP][NFC] Outline common functionality (skipUntilPragmaOpenMPEnd) The same code was repeated multiple times, we put it in a function now.
2020-02-21 13:48:56 -06: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-07 17:54:44 +00:00
}
// Skip the last annot_pragma_openmp_end.
ConsumeAnnotationToken();
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
return Actions.OpenMP().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-07 17:54:44 +00: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 04:28:39 +00:00
case OMPD_requires: {
SourceLocation StartLoc = ConsumeToken();
SmallVector<OMPClause *, 5> Clauses;
[clang][OpenMP] Shorten directive classification in ParseOpenMP (#94691) Use directive categories to simplify long lists of `case` statements in the OpenMP parser. This is a step towards avoiding dependence on explicitly specified sets of directives that can be expressed more generically. The upcoming OpenMP 6.0 will introduce many new combined directives, and the more generically we handle directives, the easier the introduction of the new standard will be. --------- Co-authored-by: Alexey Bataev <a.bataev@outlook.com>
2024-06-26 08:11:09 -05:00
llvm::SmallBitVector SeenClauses(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 04:28:39 +00: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 11:01:50 +00: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 04:28:39 +00:00
<< getOpenMPDirectiveName(OMPD_requires);
break;
}
while (Tok.isNot(tok::annot_pragma_openmp_end)) {
OpenMPClauseKind CKind = Tok.isAnnotation()
? OMPC_unknown
: getOpenMPClauseKind(PP.getSpelling(Tok));
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
Actions.OpenMP().StartOpenMPClause(CKind);
[clang][OpenMP] Simplify check for repeated clauses (#93611) The `FirstClauses` is a vector of pointer-bool pairs, and the pointer part of the pair is never used. Replace the vector with std::bitset, and rename it to `SeenClauses` to make the purpose of it a bit clearer.
2024-05-30 14:49:13 -05:00
OMPClause *Clause = ParseOpenMPClause(OMPD_requires, CKind,
!SeenClauses[unsigned(CKind)]);
[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-12 18:52:33 +00:00
SkipUntil(tok::comma, tok::identifier, tok::annot_pragma_openmp_end,
StopBeforeMatch);
[clang][OpenMP] Simplify check for repeated clauses (#93611) The `FirstClauses` is a vector of pointer-bool pairs, and the pointer part of the pair is never used. Replace the vector with std::bitset, and rename it to `SeenClauses` to make the purpose of it a bit clearer.
2024-05-30 14:49:13 -05:00
SeenClauses[unsigned(CKind)] = 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 04:28:39 +00:00
if (Clause != nullptr)
Clauses.push_back(Clause);
if (Tok.is(tok::annot_pragma_openmp_end)) {
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
Actions.OpenMP().EndOpenMPClause();
[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 04:28:39 +00:00
break;
}
// Skip ',' if any.
if (Tok.is(tok::comma))
ConsumeToken();
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
Actions.OpenMP().EndOpenMPClause();
[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 04:28:39 +00:00
}
// 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-11 15:15:21 -05: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 04:28:39 +00:00
Diag(Tok, diag::err_omp_expected_clause)
<< getOpenMPDirectiveName(OMPD_requires);
ConsumeAnnotationToken();
return nullptr;
}
ConsumeAnnotationToken();
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
return Actions.OpenMP().ActOnOpenMPRequiresDirective(StartLoc, Clauses);
[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 04:28:39 +00:00
}
[OPENMP]Initial support for at clause Error directive is allowed in both declared and executable contexts. The function ActOnOpenMPAtClause is called in both places during the parsers. Adding a param "bool InExContext" to identify context which is used to emit error massage. Differential Revision: https://reviews.llvm.org/D137851
2022-11-10 18:12:35 -08:00
case OMPD_error: {
SmallVector<OMPClause *, 1> Clauses;
SourceLocation StartLoc = ConsumeToken();
ParseOpenMPClauses(DKind, Clauses, StartLoc);
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
Actions.OpenMP().ActOnOpenMPErrorDirective(Clauses, StartLoc,
SourceLocation(),
/*InExContext = */ false);
[OPENMP]Initial support for at clause Error directive is allowed in both declared and executable contexts. The function ActOnOpenMPAtClause is called in both places during the parsers. Adding a param "bool InExContext" to identify context which is used to emit error massage. Differential Revision: https://reviews.llvm.org/D137851
2022-11-10 18:12:35 -08:00
break;
}
[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-23 11:48:59 -06: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 05:21:39 +00:00
case OMPD_declare_reduction:
ConsumeToken();
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-23 19:53:05 +00: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-21 13:48:56 -06: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 05:21:39 +00: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-18 19:21:48 +00: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 05:21:39 +00: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-01 20:25:04 +00: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-20 19:50:47 -06: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();
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
OMPTraitInfo *ParentTI =
Actions.OpenMP().getOMPTraitInfoForSurroundingScope();
[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 01:05:51 -05:00
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-12 14:55:00 -07: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-20 19:50:47 -06: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-12 14:55:00 -07: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-20 19:50:47 -06: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 11:02:49 -04: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-20 19:50:47 -06: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-03 11:29:53 -05: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 01:08:03 -05:00
[clang-format] Format ParseOpenMP.cpp changes Properly format D116549.
2022-01-27 08:55:08 +00: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_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-16 11:28:31 -05:00
TargetOMPContext OMPCtx(
ASTCtx, std::move(DiagUnknownTrait),
/* CurrentFunctionDecl */ nullptr,
[OpenMP]Initial parsing/sema support for target_device selector set (#118471) This patch adds initial support for target_device selector set - Section 9.2 (Spec 6.0)
2025-02-05 19:24:24 +05:30
/* ConstructTraits */ ArrayRef<llvm::omp::TraitProperty>(),
Actions.OpenMP().getOpenMPDeviceNum());
[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-20 19:50:47 -06: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-03 11:29:53 -05:00
if (isVariantApplicableInContext(VMI, OMPCtx, /* DeviceSetOnly */ true)) {
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
Actions.OpenMP().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-20 19:50:47 -06: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-25 14: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-20 19:50:47 -06: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-25 14:04:06 -08:00
case OMPD_end_declare_variant: {
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
if (Actions.OpenMP().isInOpenMPDeclareVariantScope())
Actions.OpenMP().ActOnOpenMPEndDeclareVariant();
[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-25 14:04:06 -08:00
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-20 19:50:47 -06: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-25 14: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-13 20:18:17 +00: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 10:43:55 +00: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-13 20:18:17 +00: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 10:43:55 +00: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 12:45:37 +00: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-13 20:18:17 +00: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-29 18:44:28 -05: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 05:28:34 +00: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 10:43:55 +00: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 06:51:19 -04: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-07 13:39:18 -05:00
Ptr = ParseOpenMPDeclarativeDirectiveWithExtDecl(AS, Attrs, Delayed,
TagType, Tag);
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-23 19:53:05 +00: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 10:43:55 +00:00
// Here we expect to see some function declaration.
if (AS == AS_none) {
assert(TagType == DeclSpec::TST_unspecified);
parse: process GNU and standard attributes on top-level decls We would previously reject valid input where GNU attributes preceded the standard attributes on top-level declarations. A previous attribute handling change had begun rejecting this whilst GCC does honour this layout. In practice, this breaks use of `extern "C"` attributed functions which use both standard and GNU attributes as experienced by the Swift runtime. Objective-C deserves an honourable mention for requiring some additional special casing. Because attributes on declarations and definitions differ in semantics, we need to replicate some of the logic for detecting attributes to declarations to which they appertain cannot be attributed. This should match the existing case for the application of GNU attributes to interfaces, protocols, and implementations. Take the opportunity to split out the tooling tests into two cases: ones which process macros and ones which do not. Special thanks to Aaron Ballman for the many hints and extensive rubber ducking that was involved in identifying the various places where we accidentally dropped attributes. Differential Revision: https://reviews.llvm.org/D137979 Fixes: #58229 Reviewed By: aaron.ballman, arphaman
2022-11-15 15:44:34 +00:00
ParsedAttributes EmptyDeclSpecAttrs(AttrFactory);
[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 10:43:55 +00:00
MaybeParseCXX11Attributes(Attrs);
ParsingDeclSpec PDS(*this);
parse: process GNU and standard attributes on top-level decls We would previously reject valid input where GNU attributes preceded the standard attributes on top-level declarations. A previous attribute handling change had begun rejecting this whilst GCC does honour this layout. In practice, this breaks use of `extern "C"` attributed functions which use both standard and GNU attributes as experienced by the Swift runtime. Objective-C deserves an honourable mention for requiring some additional special casing. Because attributes on declarations and definitions differ in semantics, we need to replicate some of the logic for detecting attributes to declarations to which they appertain cannot be attributed. This should match the existing case for the application of GNU attributes to interfaces, protocols, and implementations. Take the opportunity to split out the tooling tests into two cases: ones which process macros and ones which do not. Special thanks to Aaron Ballman for the many hints and extensive rubber ducking that was involved in identifying the various places where we accidentally dropped attributes. Differential Revision: https://reviews.llvm.org/D137979 Fixes: #58229 Reviewed By: aaron.ballman, arphaman
2022-11-15 15:44:34 +00:00
Ptr = ParseExternalDeclaration(Attrs, EmptyDeclSpecAttrs, &PDS);
[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 10:43:55 +00:00
} 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-13 20:18:17 +00: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 10:43:55 +00: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-13 20:18:17 +00: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-18 16:24:31 +00: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 10:43:55 +00: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 00:57:28 -05: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 11:38:59 +00: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 00:57:28 -05:00
bool HasClauses = Tok.isNot(tok::annot_pragma_openmp_end);
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
SemaOpenMP::DeclareTargetContextInfo DTCI(DKind, DTLoc);
[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 00:57:28 -05:00
if (HasClauses)
ParseOMPDeclareTargetClauses(DTCI);
[clang] Don't use Optional::hasValue (NFC) This patch replaces x.hasValue() with x where x is contextually convertible to bool.
2022-06-26 18:51:54 -07:00
bool HasImplicitMappings = DKind == OMPD_begin_declare_target ||
!HasClauses ||
(DTCI.ExplicitlyMapped.empty() && DTCI.Indirect);
[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 14:59:13 +00: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 11:38:59 +00: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 00:57:28 -05:00
if (HasImplicitMappings) {
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
Actions.OpenMP().ActOnStartOpenMPDeclareTargetContext(DTCI);
[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 00:57:28 -05:00
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 11:38:59 +00:00
}
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
Actions.OpenMP().ActOnFinishedOpenMPDeclareTargetContext(DTCI);
[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 00:57:28 -05:00
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 14:28:54 +00: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 11:38:59 +00: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 00:57:28 -05:00
case OMPD_end_declare_target: {
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
if (!Actions.OpenMP().isInOpenMPDeclareTargetContext()) {
[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 00:57:28 -05:00
Diag(Tok, diag::err_omp_unexpected_directive)
<< 1 << getOpenMPDirectiveName(DKind);
break;
}
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
const SemaOpenMP::DeclareTargetContextInfo &DTCI =
Actions.OpenMP().ActOnOpenMPEndDeclareTargetDirective();
[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 00:57:28 -05:00
ParseOMPEndDeclareTargetDirective(DTCI.Kind, DKind, DTCI.Loc);
return nullptr;
}
[OpenMP] OpenMP 5.1 "assume" directive parsing support (#92731) This is a minimal patch to support parsing for "omp assume" directives. These are meant to be hints to a compiler's optimisers: as such, it is legitimate (if not very useful) to ignore them. The patch builds on top of the existing support for "omp assumes" directives (note spelling!). Unlike the "omp [begin/end] assumes" directives, "omp assume" is associated with a compound statement, i.e. it can appear within a function. The "holds" assumption could (theoretically) be mapped onto the existing builtin "__builtin_assume", though the latter applies to a single point in the program, and the former to a range (i.e. the whole of the associated compound statement). This patch fixes sollve's OpenMP 5.1 "omp assume"-based tests.
2024-08-05 12:37:07 +01:00
case OMPD_assume: {
Diag(Tok, diag::err_omp_unexpected_directive)
<< 1 << getOpenMPDirectiveName(DKind);
break;
}
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 06:34:35 +00:00
case OMPD_unknown:
Diag(Tok, diag::err_omp_unknown_directive);
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-01 20:57:11 -04:00
default:
[clang][OpenMP] Shorten directive classification in ParseOpenMP (#94691) Use directive categories to simplify long lists of `case` statements in the OpenMP parser. This is a step towards avoiding dependence on explicitly specified sets of directives that can be expressed more generically. The upcoming OpenMP 6.0 will introduce many new combined directives, and the more generically we handle directives, the easier the introduction of the new standard will be. --------- Co-authored-by: Alexey Bataev <a.bataev@outlook.com>
2024-06-26 08:11:09 -05:00
switch (getDirectiveCategory(DKind)) {
case Category::Executable:
case Category::Meta:
case Category::Subsidiary:
case Category::Utility:
Diag(Tok, diag::err_omp_unexpected_directive)
<< 1 << getOpenMPDirectiveName(DKind);
break;
case Category::Declarative:
case Category::Informational:
break;
}
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 06:34:35 +00: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 05:21:39 +00:00
while (Tok.isNot(tok::annot_pragma_openmp_end))
ConsumeAnyToken();
ConsumeAnyToken();
OpaquePtr: Use nullptr construction for DeclGroupPtrTy OpaquePtr typedef llvm-svn: 257956
2016-01-15 23:43:25 +00:00
return nullptr;
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 06:34:35 +00:00
}
[clang][OpenMP] Shorten directive classification in ParseOpenMP (#94691) Use directive categories to simplify long lists of `case` statements in the OpenMP parser. This is a step towards avoiding dependence on explicitly specified sets of directives that can be expressed more generically. The upcoming OpenMP 6.0 will introduce many new combined directives, and the more generically we handle directives, the easier the introduction of the new standard will be. --------- Co-authored-by: Alexey Bataev <a.bataev@outlook.com>
2024-06-26 08:11:09 -05:00
StmtResult Parser::ParseOpenMPExecutableDirective(
ParsedStmtContext StmtCtx, OpenMPDirectiveKind DKind, SourceLocation Loc,
bool ReadDirectiveWithinMetadirective) {
[clang][OpenMP] Implement `isOpenMPExecutableDirective` (#97089) What is considered "executable" in clang differs slightly from the OpenMP's "executable" category. In addition to the executable category, subsidiary directives, and OMPD_error are considered executable. Implement a function that performs that check.
2024-06-29 09:37:32 -05:00
assert(isOpenMPExecutableDirective(DKind) && "Unexpected directive category");
[clang][OpenMP] Shorten directive classification in ParseOpenMP (#94691) Use directive categories to simplify long lists of `case` statements in the OpenMP parser. This is a step towards avoiding dependence on explicitly specified sets of directives that can be expressed more generically. The upcoming OpenMP 6.0 will introduce many new combined directives, and the more generically we handle directives, the easier the introduction of the new standard will be. --------- Co-authored-by: Alexey Bataev <a.bataev@outlook.com>
2024-06-26 08:11:09 -05:00
bool HasAssociatedStatement = true;
Association Assoc = getDirectiveAssociation(DKind);
// OMPD_ordered has None as association, but it comes in two variants,
// the second of which is associated with a block.
// OMPD_scan and OMPD_section are both "separating", but section is treated
// as if it was associated with a statement, while scan is not.
if (DKind != OMPD_ordered && DKind != OMPD_section &&
(Assoc == Association::None || Assoc == Association::Separating)) {
if ((StmtCtx & ParsedStmtContext::AllowStandaloneOpenMPDirectives) ==
ParsedStmtContext()) {
Diag(Tok, diag::err_omp_immediate_directive)
<< getOpenMPDirectiveName(DKind) << 0;
if (DKind == OMPD_error) {
SkipUntil(tok::annot_pragma_openmp_end);
return StmtError();
}
}
HasAssociatedStatement = false;
}
SourceLocation EndLoc;
SmallVector<OMPClause *, 5> Clauses;
llvm::SmallBitVector SeenClauses(llvm::omp::Clause_enumSize + 1);
DeclarationNameInfo DirName;
OpenMPDirectiveKind CancelRegion = OMPD_unknown;
unsigned ScopeFlags = Scope::FnScope | Scope::DeclScope |
Scope::CompoundStmtScope | Scope::OpenMPDirectiveScope;
// Special processing for flush and depobj clauses.
Token ImplicitTok;
bool ImplicitClauseAllowed = false;
if (DKind == OMPD_flush || DKind == OMPD_depobj) {
ImplicitTok = Tok;
ImplicitClauseAllowed = true;
}
ConsumeToken();
// 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();
}
} else if (DKind == OMPD_cancellation_point || DKind == OMPD_cancel) {
CancelRegion = parseOpenMPDirectiveKind(*this);
if (Tok.isNot(tok::annot_pragma_openmp_end))
ConsumeToken();
}
if (isOpenMPLoopDirective(DKind))
ScopeFlags |= Scope::OpenMPLoopDirectiveScope;
if (isOpenMPSimdDirective(DKind))
ScopeFlags |= Scope::OpenMPSimdDirectiveScope;
ParseScope OMPDirectiveScope(this, ScopeFlags);
Actions.OpenMP().StartOpenMPDSABlock(DKind, DirName, Actions.getCurScope(),
Loc);
while (Tok.isNot(tok::annot_pragma_openmp_end)) {
// 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;
}
bool HasImplicitClause = false;
if (ImplicitClauseAllowed && Tok.is(tok::l_paren)) {
HasImplicitClause = true;
// Push copy of the current token back to stream to properly parse
// pseudo-clause OMPFlushClause or OMPDepobjClause.
PP.EnterToken(Tok, /*IsReinject*/ true);
PP.EnterToken(ImplicitTok, /*IsReinject*/ true);
ConsumeAnyToken();
}
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;
Actions.OpenMP().StartOpenMPClause(CKind);
HasImplicitClause = false;
OMPClause *Clause =
ParseOpenMPClause(DKind, CKind, !SeenClauses[unsigned(CKind)]);
SeenClauses[unsigned(CKind)] = true;
if (Clause)
Clauses.push_back(Clause);
// Skip ',' if any.
if (Tok.is(tok::comma))
ConsumeToken();
Actions.OpenMP().EndOpenMPClause();
}
// End location of the directive.
EndLoc = Tok.getLocation();
// Consume final annot_pragma_openmp_end.
ConsumeAnnotationToken();
if (DKind == OMPD_ordered) {
// If the depend or doacross clause is specified, the ordered construct
// is a stand-alone directive.
for (auto CK : {OMPC_depend, OMPC_doacross}) {
if (SeenClauses[unsigned(CK)]) {
if ((StmtCtx & ParsedStmtContext::AllowStandaloneOpenMPDirectives) ==
ParsedStmtContext()) {
Diag(Loc, diag::err_omp_immediate_directive)
<< getOpenMPDirectiveName(DKind) << 1 << getOpenMPClauseName(CK);
}
HasAssociatedStatement = false;
}
}
}
[Clang] [OpenMP] Add support for '#pragma omp stripe'. (#126927) This patch was reviewed and approved here: https://github.com/llvm/llvm-project/pull/119891 However it has been reverted here: https://github.com/alejandro-alvarez-sonarsource/llvm-project/commit/083df25dc256154cccbc0e127d79fbac4d0583c5 due to a build issue here: https://lab.llvm.org/buildbot/#/builders/51/builds/10694 This patch is reintroducing the support.
2025-02-13 07:14:36 -05:00
if ((DKind == OMPD_tile || DKind == OMPD_stripe) &&
!SeenClauses[unsigned(OMPC_sizes)]) {
[clang][OpenMP] Shorten directive classification in ParseOpenMP (#94691) Use directive categories to simplify long lists of `case` statements in the OpenMP parser. This is a step towards avoiding dependence on explicitly specified sets of directives that can be expressed more generically. The upcoming OpenMP 6.0 will introduce many new combined directives, and the more generically we handle directives, the easier the introduction of the new standard will be. --------- Co-authored-by: Alexey Bataev <a.bataev@outlook.com>
2024-06-26 08:11:09 -05:00
Diag(Loc, diag::err_omp_required_clause)
[Clang] [OpenMP] Add support for '#pragma omp stripe'. (#126927) This patch was reviewed and approved here: https://github.com/llvm/llvm-project/pull/119891 However it has been reverted here: https://github.com/alejandro-alvarez-sonarsource/llvm-project/commit/083df25dc256154cccbc0e127d79fbac4d0583c5 due to a build issue here: https://lab.llvm.org/buildbot/#/builders/51/builds/10694 This patch is reintroducing the support.
2025-02-13 07:14:36 -05:00
<< getOpenMPDirectiveName(DKind) << "sizes";
[clang][OpenMP] Shorten directive classification in ParseOpenMP (#94691) Use directive categories to simplify long lists of `case` statements in the OpenMP parser. This is a step towards avoiding dependence on explicitly specified sets of directives that can be expressed more generically. The upcoming OpenMP 6.0 will introduce many new combined directives, and the more generically we handle directives, the easier the introduction of the new standard will be. --------- Co-authored-by: Alexey Bataev <a.bataev@outlook.com>
2024-06-26 08:11:09 -05:00
}
StmtResult AssociatedStmt;
if (HasAssociatedStatement) {
// The body is a block scope like in Lambdas and Blocks.
Actions.OpenMP().ActOnOpenMPRegionStart(DKind, getCurScope());
// 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.
ParsingOpenMPDirectiveRAII NormalScope(*this, /*Value=*/false);
{
Sema::CompoundScopeRAII Scope(Actions);
AssociatedStmt = ParseStatement();
if (AssociatedStmt.isUsable() && isOpenMPLoopDirective(DKind) &&
getLangOpts().OpenMPIRBuilder)
AssociatedStmt =
Actions.OpenMP().ActOnOpenMPLoopnest(AssociatedStmt.get());
}
AssociatedStmt =
Actions.OpenMP().ActOnOpenMPRegionEnd(AssociatedStmt, Clauses);
} else if (DKind == OMPD_target_update || DKind == OMPD_target_enter_data ||
DKind == OMPD_target_exit_data) {
Actions.OpenMP().ActOnOpenMPRegionStart(DKind, getCurScope());
AssociatedStmt = (Sema::CompoundScopeRAII(Actions),
[clang] Use {} instead of std::nullopt to initialize empty ArrayRef (#109399) Follow up to #109133.
2024-10-24 10:23:40 +01:00
Actions.ActOnCompoundStmt(Loc, Loc, {},
[clang][OpenMP] Shorten directive classification in ParseOpenMP (#94691) Use directive categories to simplify long lists of `case` statements in the OpenMP parser. This is a step towards avoiding dependence on explicitly specified sets of directives that can be expressed more generically. The upcoming OpenMP 6.0 will introduce many new combined directives, and the more generically we handle directives, the easier the introduction of the new standard will be. --------- Co-authored-by: Alexey Bataev <a.bataev@outlook.com>
2024-06-26 08:11:09 -05:00
/*isStmtExpr=*/false));
AssociatedStmt =
Actions.OpenMP().ActOnOpenMPRegionEnd(AssociatedStmt, Clauses);
}
StmtResult Directive = Actions.OpenMP().ActOnOpenMPExecutableDirective(
DKind, DirName, CancelRegion, Clauses, AssociatedStmt.get(), Loc, EndLoc);
// Exit scope.
Actions.OpenMP().EndOpenMPDSABlock(Directive.get());
OMPDirectiveScope.Exit();
return Directive;
}
[OpenMP] OpenMP 5.1 "assume" directive parsing support (#92731) This is a minimal patch to support parsing for "omp assume" directives. These are meant to be hints to a compiler's optimisers: as such, it is legitimate (if not very useful) to ignore them. The patch builds on top of the existing support for "omp assumes" directives (note spelling!). Unlike the "omp [begin/end] assumes" directives, "omp assume" is associated with a compound statement, i.e. it can appear within a function. The "holds" assumption could (theoretically) be mapped onto the existing builtin "__builtin_assume", though the latter applies to a single point in the program, and the former to a range (i.e. the whole of the associated compound statement). This patch fixes sollve's OpenMP 5.1 "omp assume"-based tests.
2024-08-05 12:37:07 +01:00
StmtResult Parser::ParseOpenMPInformationalDirective(
ParsedStmtContext StmtCtx, OpenMPDirectiveKind DKind, SourceLocation Loc,
bool ReadDirectiveWithinMetadirective) {
assert(isOpenMPInformationalDirective(DKind) &&
"Unexpected directive category");
bool HasAssociatedStatement = true;
SmallVector<OMPClause *, 5> Clauses;
llvm::SmallBitVector SeenClauses(llvm::omp::Clause_enumSize + 1);
DeclarationNameInfo DirName;
unsigned ScopeFlags = Scope::FnScope | Scope::DeclScope |
Scope::CompoundStmtScope | Scope::OpenMPDirectiveScope;
ParseScope OMPDirectiveScope(this, ScopeFlags);
Actions.OpenMP().StartOpenMPDSABlock(DKind, DirName, Actions.getCurScope(),
Loc);
while (Tok.isNot(tok::annot_pragma_openmp_end)) {
if (ReadDirectiveWithinMetadirective && Tok.is(tok::r_paren)) {
while (Tok.isNot(tok::annot_pragma_openmp_end))
ConsumeAnyToken();
break;
}
OpenMPClauseKind CKind = Tok.isAnnotation()
? OMPC_unknown
: getOpenMPClauseKind(PP.getSpelling(Tok));
Actions.OpenMP().StartOpenMPClause(CKind);
OMPClause *Clause =
ParseOpenMPClause(DKind, CKind, !SeenClauses[unsigned(CKind)]);
SeenClauses[unsigned(CKind)] = true;
if (Clause)
Clauses.push_back(Clause);
if (Tok.is(tok::comma))
ConsumeToken();
Actions.OpenMP().EndOpenMPClause();
}
SourceLocation EndLoc = Tok.getLocation();
ConsumeAnnotationToken();
StmtResult AssociatedStmt;
if (HasAssociatedStatement) {
Actions.OpenMP().ActOnOpenMPRegionStart(DKind, getCurScope());
ParsingOpenMPDirectiveRAII NormalScope(*this, /*Value=*/false);
{
Sema::CompoundScopeRAII Scope(Actions);
AssociatedStmt = ParseStatement();
}
AssociatedStmt =
Actions.OpenMP().ActOnOpenMPRegionEnd(AssociatedStmt, Clauses);
}
StmtResult Directive = Actions.OpenMP().ActOnOpenMPInformationalDirective(
DKind, DirName, Clauses, AssociatedStmt.get(), Loc, EndLoc);
Actions.OpenMP().EndOpenMPDSABlock(Directive.get());
OMPDirectiveScope.Exit();
return Directive;
}
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 01:00:01 +00:00
/// Parsing of declarative or executable OpenMP directives.
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00: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-07 17:54:44 +00: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 05:21:39 +00: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-01 20:25:04 +00: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 11:44:49 +00:00
/// executable-directive:
[OPENMP] Initial parsing and sema analysis for 'single' directive. llvm-svn: 211774
2014-06-26 12:05:45 +00:00
/// annot_pragma_openmp 'parallel' | 'simd' | 'for' | 'sections' |
[OPENMP] Parsing/Sema of the OpenMP directive 'critical'. llvm-svn: 213510
2014-07-21 09:42:05 +00: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-05 13:43:48 -05:00
/// 'parallel for' | 'parallel sections' | 'parallel master' | 'task' |
[OPENMP]Initial support for error directive. Differential Revision: https://reviews.llvm.org/D137209
2022-11-01 14:46:12 -07:00
/// 'taskyield' | 'barrier' | 'taskwait' | 'flush' | 'ordered' | 'error'
/// | 'atomic' | 'for simd' | 'parallel for simd' | 'target' | 'target
[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-05 13:43:48 -05:00
/// 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
[OpenMP][5.1] Fix parallel masked is ignored #59939 Code generation support for 'parallel masked' directive. The `EmitOMPParallelMaskedDirective` was implemented. In addition, the appropiate device functions were added. Fix #59939. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D143527
2023-04-03 20:29:16 +00:00
/// for simd' | 'target teams distribute simd' | 'masked' |
/// 'parallel masked' {clause} annot_pragma_openmp_end
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00:00
///
[OpenMP]Fix parsing of OpenMP directive nested in a metadirective Differential Revision: https://reviews.llvm.org/D119761
2022-02-14 11:36:12 -08:00
StmtResult Parser::ParseOpenMPDeclarativeOrExecutableDirective(
ParsedStmtContext StmtCtx, bool ReadDirectiveWithinMetadirective) {
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-17 16:03:01 -05:00
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-13 16:05:30 -05:00
ParsingOpenMPDirectiveRAII DirScope(*this);
Replaced bool parameters in SkipUntil function with single bit-based parameter. llvm-svn: 194994
2013-11-18 08:17:37 +00:00
ParenBraceBracketBalancer BalancerRAIIObj(*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-17 16:03:01 -05:00
SourceLocation Loc = ReadDirectiveWithinMetadirective
? Tok.getLocation()
[clang][OpenMP] Shorten directive classification in ParseOpenMP (#94691) Use directive categories to simplify long lists of `case` statements in the OpenMP parser. This is a step towards avoiding dependence on explicitly specified sets of directives that can be expressed more generically. The upcoming OpenMP 6.0 will introduce many new combined directives, and the more generically we handle directives, the easier the introduction of the new standard will be. --------- Co-authored-by: Alexey Bataev <a.bataev@outlook.com>
2024-06-26 08:11:09 -05:00
: ConsumeAnnotationToken();
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-23 19:53:05 +00: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-17 16:03:01 -05:00
if (ReadDirectiveWithinMetadirective && DKind == OMPD_unknown) {
Diag(Tok, diag::err_omp_unknown_directive);
return StmtError();
}
[clang][OpenMP] Shorten directive classification in ParseOpenMP (#94691) Use directive categories to simplify long lists of `case` statements in the OpenMP parser. This is a step towards avoiding dependence on explicitly specified sets of directives that can be expressed more generically. The upcoming OpenMP 6.0 will introduce many new combined directives, and the more generically we handle directives, the easier the introduction of the new standard will be. --------- Co-authored-by: Alexey Bataev <a.bataev@outlook.com>
2024-06-26 08:11:09 -05:00
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00:00
StmtResult Directive = StmtError();
[clang][OpenMP] Shorten directive classification in ParseOpenMP (#94691) Use directive categories to simplify long lists of `case` statements in the OpenMP parser. This is a step towards avoiding dependence on explicitly specified sets of directives that can be expressed more generically. The upcoming OpenMP 6.0 will introduce many new combined directives, and the more generically we handle directives, the easier the introduction of the new standard will be. --------- Co-authored-by: Alexey Bataev <a.bataev@outlook.com>
2024-06-26 08:11:09 -05:00
bool IsExecutable = [&]() {
if (DKind == OMPD_error) // OMPD_error is handled as executable
return true;
auto Res = getDirectiveCategory(DKind);
return Res == Category::Executable || Res == Category::Subsidiary;
}();
if (IsExecutable) {
Directive = ParseOpenMPExecutableDirective(
StmtCtx, DKind, Loc, ReadDirectiveWithinMetadirective);
assert(!Directive.isUnset() && "Executable directive remained unprocessed");
return Directive;
}
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00:00
switch (DKind) {
[Clang][OpenMP] Support for omp nothing Patch to support "#pragma omp nothing" Reviewed By: tianshilei1992 Differential Revision: https://reviews.llvm.org/D123286
2022-05-24 23:59:19 -05:00
case OMPD_nothing:
ConsumeToken();
[OpenMP] Support for `nothing` in `metadirective` (#73690) - Removed an unnecessary check that was preventing `nothing` to work properly inside `metadirective`.
2023-11-29 15:13:43 +05:30
// If we are parsing the 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();
else
skipUntilPragmaOpenMPEnd(DKind);
[Clang][OpenMP] Support for omp nothing Patch to support "#pragma omp nothing" Reviewed By: tianshilei1992 Differential Revision: https://reviews.llvm.org/D123286
2022-05-24 23:59:19 -05:00
if (Tok.is(tok::annot_pragma_openmp_end))
ConsumeAnnotationToken();
[OpenMP] return empty stmt for `nothing` (#74042) - `nothing` directive was effecting the `if` block structure which it should not. So return an empty statement instead of an error statement while parsing to avoid this.
2023-12-03 13:33:38 +05:30
// return an empty statement
return StmtEmpty();
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-17 16:03:01 -05: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
[clang-format] Format ParseOpenMP.cpp changes Properly format D116549.
2022-01-27 08:55:08 +00: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_declare_variant_isa_trait) << ISATrait;
};
[OpenMP][Clang] Allow passing target features in ISA trait for metadirective clause Passing any feature in the device-isa trait which is not supported by the host was causing a compilation failure. Differential Revision: https://reviews.llvm.org/D116549
2022-01-11 11:43:31 +00:00
TargetOMPContext OMPCtx(ASTContext, std::move(DiagUnknownTrait),
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-17 16:03:01 -05:00
/* CurrentFunctionDecl */ nullptr,
[OpenMP]Initial parsing/sema support for target_device selector set (#118471) This patch adds initial support for target_device selector set - Section 9.2 (Spec 6.0)
2025-02-05 19:24:24 +05:30
ArrayRef<llvm::omp::TraitProperty>(),
Actions.OpenMP().getOpenMPDeviceNum());
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-17 16:03:01 -05:00
// 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
[OpenMP]Fix parsing of OpenMP directive nested in a metadirective Differential Revision: https://reviews.llvm.org/D119761
2022-02-14 11:36:12 -08:00
Directive = ParseOpenMPDeclarativeOrExecutableDirective(
StmtCtx,
/*ReadDirectiveWithinMetadirective=*/true);
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-17 16:03:01 -05:00
break;
}
[OpenMP] Missing implicit otherwise clause in metadirective. (#127113) Compiling this: `int main() {` ` #pragma omp metadirective when(use r= {condition(0)}` `: parallel for)` `for (int i=0; i<10; i++)` ; }` is generating an error: `error: expected expression` The compiler is interpreting this as if it's compiling a `#pragma omp metadirective` with no `otherwise` clause. In the OMP5.2 specs chapter 7.4 it's mentioned that: `If no otherwise clause is specified the effect is as if one was specified without an associated directive variant.` This patch fixes the issue.
2025-02-28 08:02:35 -05:00
// If no match is found and no otherwise clause is present, skip
// OMP5.2 Chapter 7.4: If no otherwise clause is specified the effect is as
// if one was specified without an associated directive variant.
if (BestIdx == -1 && Idx == 1) {
assert(Tok.is(tok::annot_pragma_openmp_end) &&
"Expecting the end of the pragma here");
ConsumeAnnotationToken();
return StmtEmpty();
}
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-17 16:03:01 -05: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 14:59:13 +00: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 00:27:53 +00:00
// FIXME: Should this be permitted in C++?
[C23] Complete support for WG14 N2508 (#71398) In Clang 16, we implemented the ability to add a label at the end of a compound statement. These changes complete the implementation by allowing a label to be followed by a declaration in C. Note, this seems to have fixed an issue with some OpenMP stand-alone directives not being properly diagnosed as per: https://www.openmp.org/spec-html/5.1/openmpsu19.html#x34-330002.1.3 (The same requirement exists in OpenMP 5.2 as well.)
2023-11-20 10:52:11 -05:00
if ((StmtCtx & ParsedStmtContext::AllowStandaloneOpenMPDirectives) ==
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 00:27:53 +00:00
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 11:18:54 +00:00
Diag(Tok, diag::err_omp_immediate_directive)
<< getOpenMPDirectiveName(DKind) << 0;
}
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00: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-07 17:54:44 +00: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-21 13:48:56 -06:00
skipUntilPragmaOpenMPEnd(DKind);
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
DeclGroupPtrTy Res = Actions.OpenMP().ActOnOpenMPThreadprivateDirective(
[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 14:59:13 +00:00
Loc, Helper.getIdentifiers());
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00: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-18 19:10:49 +00:00
SkipUntil(tok::annot_pragma_openmp_end);
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00: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 14:59:13 +00: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-07 17:54:44 +00:00
case OMPD_allocate: {
// FIXME: Should this be permitted in C++?
[C23] Complete support for WG14 N2508 (#71398) In Clang 16, we implemented the ability to add a label at the end of a compound statement. These changes complete the implementation by allowing a label to be followed by a declaration in C. Note, this seems to have fixed an issue with some OpenMP stand-alone directives not being properly diagnosed as per: https://www.openmp.org/spec-html/5.1/openmpsu19.html#x34-330002.1.3 (The same requirement exists in OpenMP 5.2 as well.)
2023-11-20 10:52:11 -05:00
if ((StmtCtx & ParsedStmtContext::AllowStandaloneOpenMPDirectives) ==
[OPENMP 5.0]Add initial support for 'allocate' directive. Added parsing/sema analysis/serialization/deserialization support for 'allocate' directive. llvm-svn: 355614
2019-03-07 17:54:44 +00:00
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-12 18:52:33 +00: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-07 17:54:44 +00:00
if (Tok.isNot(tok::annot_pragma_openmp_end)) {
[clang][OpenMP] Shorten directive classification in ParseOpenMP (#94691) Use directive categories to simplify long lists of `case` statements in the OpenMP parser. This is a step towards avoiding dependence on explicitly specified sets of directives that can be expressed more generically. The upcoming OpenMP 6.0 will introduce many new combined directives, and the more generically we handle directives, the easier the introduction of the new standard will be. --------- Co-authored-by: Alexey Bataev <a.bataev@outlook.com>
2024-06-26 08:11:09 -05:00
llvm::SmallBitVector SeenClauses(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-12 18:52:33 +00:00
while (Tok.isNot(tok::annot_pragma_openmp_end)) {
OpenMPClauseKind CKind =
Tok.isAnnotation() ? OMPC_unknown
: getOpenMPClauseKind(PP.getSpelling(Tok));
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
Actions.OpenMP().StartOpenMPClause(CKind);
[clang][OpenMP] Simplify check for repeated clauses (#93611) The `FirstClauses` is a vector of pointer-bool pairs, and the pointer part of the pair is never used. Replace the vector with std::bitset, and rename it to `SeenClauses` to make the purpose of it a bit clearer.
2024-05-30 14:49:13 -05:00
OMPClause *Clause = ParseOpenMPClause(OMPD_allocate, CKind,
!SeenClauses[unsigned(CKind)]);
[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-12 18:52:33 +00:00
SkipUntil(tok::comma, tok::identifier, tok::annot_pragma_openmp_end,
StopBeforeMatch);
[clang][OpenMP] Simplify check for repeated clauses (#93611) The `FirstClauses` is a vector of pointer-bool pairs, and the pointer part of the pair is never used. Replace the vector with std::bitset, and rename it to `SeenClauses` to make the purpose of it a bit clearer.
2024-05-30 14:49:13 -05:00
SeenClauses[unsigned(CKind)] = 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-12 18:52:33 +00:00
if (Clause != nullptr)
Clauses.push_back(Clause);
if (Tok.is(tok::annot_pragma_openmp_end)) {
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
Actions.OpenMP().EndOpenMPClause();
[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-12 18:52:33 +00:00
break;
}
// Skip ',' if any.
if (Tok.is(tok::comma))
ConsumeToken();
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
Actions.OpenMP().EndOpenMPClause();
[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-12 18:52:33 +00:00
}
[OpenMP][NFC] Outline common functionality (skipUntilPragmaOpenMPEnd) The same code was repeated multiple times, we put it in a function now.
2020-02-21 13:48:56 -06: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-07 17:54:44 +00:00
}
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
DeclGroupPtrTy Res = Actions.OpenMP().ActOnOpenMPAllocateDirective(
[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-12 18:52:33 +00:00
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-07 17:54:44 +00: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 05:21:39 +00:00
case OMPD_declare_reduction:
ConsumeToken();
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-23 19:53:05 +00: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-21 13:48:56 -06: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 05:21:39 +00:00
ConsumeAnyToken();
Directive = Actions.ActOnDeclStmt(Res, Loc, Tok.getLocation());
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-23 19:53:05 +00: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 05:21:39 +00:00
SkipUntil(tok::annot_pragma_openmp_end);
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-23 19:53:05 +00: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 05:21:39 +00: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-01 20:25:04 +00: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] Parse and Sema support for declare target in local scope (#83223) - adds Parse and Sema support for the `declare target` directive inside a function scope.
2024-03-06 19:46:23 +05:30
case OMPD_declare_target: {
SourceLocation DTLoc = ConsumeAnyToken();
bool HasClauses = Tok.isNot(tok::annot_pragma_openmp_end);
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
SemaOpenMP::DeclareTargetContextInfo DTCI(DKind, DTLoc);
[OpenMP] Parse and Sema support for declare target in local scope (#83223) - adds Parse and Sema support for the `declare target` directive inside a function scope.
2024-03-06 19:46:23 +05:30
if (HasClauses)
ParseOMPDeclareTargetClauses(DTCI);
bool HasImplicitMappings =
!HasClauses || (DTCI.ExplicitlyMapped.empty() && DTCI.Indirect);
if (HasImplicitMappings) {
Diag(Tok, diag::err_omp_unexpected_directive)
<< 1 << getOpenMPDirectiveName(DKind);
SkipUntil(tok::annot_pragma_openmp_end);
break;
}
// Skip the last annot_pragma_openmp_end.
ConsumeAnyToken();
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
Actions.OpenMP().ActOnFinishedOpenMPDeclareTargetContext(DTCI);
[OpenMP] Parse and Sema support for declare target in local scope (#83223) - adds Parse and Sema support for the `declare target` directive inside a function scope.
2024-03-06 19:46:23 +05:30
break;
}
[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 10:43:55 +00:00
case OMPD_declare_simd:
[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 00:57:28 -05: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 11:38:59 +00: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 04:28:39 +00: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-20 19:50:47 -06: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-13 20:18:17 +00: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 10:43:55 +00: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-16 18:36:44 +00: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 10:43:55 +00:00
SkipUntil(tok::annot_pragma_openmp_end);
break;
[OpenMP] OpenMP 5.1 "assume" directive parsing support (#92731) This is a minimal patch to support parsing for "omp assume" directives. These are meant to be hints to a compiler's optimisers: as such, it is legitimate (if not very useful) to ignore them. The patch builds on top of the existing support for "omp assumes" directives (note spelling!). Unlike the "omp [begin/end] assumes" directives, "omp assume" is associated with a compound statement, i.e. it can appear within a function. The "holds" assumption could (theoretically) be mapped onto the existing builtin "__builtin_assume", though the latter applies to a single point in the program, and the former to a range (i.e. the whole of the associated compound statement). This patch fixes sollve's OpenMP 5.1 "omp assume"-based tests.
2024-08-05 12:37:07 +01:00
case OMPD_assume: {
ConsumeToken();
Directive = ParseOpenMPInformationalDirective(
StmtCtx, DKind, Loc, ReadDirectiveWithinMetadirective);
assert(!Directive.isUnset() &&
"Informational directive remains unprocessed");
return Directive;
}
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00: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-01 20:57:11 -04:00
default:
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00: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-18 19:10:49 +00:00
SkipUntil(tok::annot_pragma_openmp_end);
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00: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 14:59:13 +00: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-29 18:44:28 -05: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 14:59:13 +00:00
bool AllowScopeSpecifier) {
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 06:34:35 +00: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-18 19:10:49 +00: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 03:13:43 +00: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-04 22:00:49 -06:00
getOpenMPDirectiveName(Kind).data()))
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00:00
return true;
bool IsCorrect = true;
OpenMP threadprivate with qualified names. llvm-svn: 181683
2013-05-13 04:18:18 +00:00
bool NoIdentIsFound = true;
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 06:34:35 +00:00
// Read tokens while ')' or annot_pragma_openmp_end is not found.
OpenMP threadprivate with qualified names. llvm-svn: 181683
2013-05-13 04:18:18 +00: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 06:34:35 +00:00
CXXScopeSpec SS;
UnqualifiedId Name;
// Read var name.
Token PrevTok = Tok;
OpenMP threadprivate with qualified names. llvm-svn: 181683
2013-05-13 04:18:18 +00:00
NoIdentIsFound = false;
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 06:34:35 +00:00
OpenMP threadprivate with qualified names. llvm-svn: 181683
2013-05-13 04:18:18 +00: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 09:12:29 +01:00
ParseOptionalCXXScopeSpecifier(SS, /*ObjectType=*/nullptr,
[clang] Fix bugprone argument comments (NFC) Identified with bugprone-argument-comment.
2022-01-09 00:19:49 -08:00
/*ObjectHasErrors=*/false, false)) {
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 06:34:35 +00: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-18 19:10:49 +00: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 09:12:29 +01: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 04:18:18 +00: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-18 19:10:49 +00:00
StopBeforeMatch);
OpenMP threadprivate with qualified names. llvm-svn: 181683
2013-05-13 04:18:18 +00: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 06:34:35 +00: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-18 19:10:49 +00: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 09:48:30 +00: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 06:34:35 +00: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 14:59:13 +00:00
Callback(SS, Actions.GetNameFromUnqualifiedId(Name));
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 06:34:35 +00:00
}
// Consume ','.
if (Tok.is(tok::comma)) {
ConsumeToken();
}
OpenMP threadprivate with qualified names. llvm-svn: 181683
2013-05-13 04:18:18 +00:00
}
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 06:34:35 +00:00
OpenMP threadprivate with qualified names. llvm-svn: 181683
2013-05-13 04:18:18 +00: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 09:48:30 +00:00
Diag(Tok, diag::err_expected) << tok::identifier;
OpenMP threadprivate with qualified names. llvm-svn: 181683
2013-05-13 04:18:18 +00:00
IsCorrect = false;
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 06:34:35 +00:00
}
OpenMP threadprivate with qualified names. llvm-svn: 181683
2013-05-13 04:18:18 +00:00
// Parse ')'.
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00:00
IsCorrect = !T.consumeClose() && IsCorrect;
OpenMP threadprivate with qualified names. llvm-svn: 181683
2013-05-13 04:18:18 +00: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 14:59:13 +00:00
return !IsCorrect;
OpenMP threadprivate directive parsing and semantic analysis llvm-svn: 177705
2013-03-22 06:34:35 +00:00
}
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00: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-12 11:26:59 -08:00
OMPClause *Parser::ParseOpenMPSizesClause() {
[Clang][OpenMP][Tile] Allow non-constant tile sizes. (#91345) Allow non-constants in the `sizes` clause such as ``` #pragma omp tile sizes(a) for (int i = 0; i < n; ++i) ``` This is permitted since tile was introduced in [OpenMP 5.1](https://www.openmp.org/spec-html/5.1/openmpsu53.html#x78-860002.11.9). It is possible to sneak-in negative numbers at runtime as in ``` int a = -1; #pragma omp tile sizes(a) ``` Even though it is not well-formed, it should still result in every loop iteration to be executed exactly once, an invariant of the tile construct that we should ensure. `ParseOpenMPExprListClause` is extracted-out to be reused by the `permutation` clause of the `interchange` construct. Some care was put into ensuring correct behavior in template contexts.
2024-05-13 16:10:58 +02:00
SourceLocation ClauseNameLoc, OpenLoc, CloseLoc;
[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-12 11:26:59 -08:00
SmallVector<Expr *, 4> ValExprs;
[Clang][OpenMP][Tile] Allow non-constant tile sizes. (#91345) Allow non-constants in the `sizes` clause such as ``` #pragma omp tile sizes(a) for (int i = 0; i < n; ++i) ``` This is permitted since tile was introduced in [OpenMP 5.1](https://www.openmp.org/spec-html/5.1/openmpsu53.html#x78-860002.11.9). It is possible to sneak-in negative numbers at runtime as in ``` int a = -1; #pragma omp tile sizes(a) ``` Even though it is not well-formed, it should still result in every loop iteration to be executed exactly once, an invariant of the tile construct that we should ensure. `ParseOpenMPExprListClause` is extracted-out to be reused by the `permutation` clause of the `interchange` construct. Some care was put into ensuring correct behavior in template contexts.
2024-05-13 16:10:58 +02:00
if (ParseOpenMPExprListClause(OMPC_sizes, ClauseNameLoc, OpenLoc, CloseLoc,
ValExprs))
[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-12 11:26:59 -08:00
return nullptr;
[Clang][OpenMP][Tile] Allow non-constant tile sizes. (#91345) Allow non-constants in the `sizes` clause such as ``` #pragma omp tile sizes(a) for (int i = 0; i < n; ++i) ``` This is permitted since tile was introduced in [OpenMP 5.1](https://www.openmp.org/spec-html/5.1/openmpsu53.html#x78-860002.11.9). It is possible to sneak-in negative numbers at runtime as in ``` int a = -1; #pragma omp tile sizes(a) ``` Even though it is not well-formed, it should still result in every loop iteration to be executed exactly once, an invariant of the tile construct that we should ensure. `ParseOpenMPExprListClause` is extracted-out to be reused by the `permutation` clause of the `interchange` construct. Some care was put into ensuring correct behavior in template contexts.
2024-05-13 16:10:58 +02:00
return Actions.OpenMP().ActOnOpenMPSizesClause(ValExprs, ClauseNameLoc,
OpenLoc, CloseLoc);
[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-12 11:26:59 -08:00
}
[Clang][OpenMP] Add permutation clause (#92030) Add the permutation clause for the interchange directive which will be introduced in the upcoming OpenMP 6.0 specification. A preview has been published in [Technical Report12](https://www.openmp.org/wp-content/uploads/openmp-TR12.pdf).
2024-10-09 14:56:43 +02:00
OMPClause *Parser::ParseOpenMPPermutationClause() {
SourceLocation ClauseNameLoc, OpenLoc, CloseLoc;
SmallVector<Expr *> ArgExprs;
if (ParseOpenMPExprListClause(OMPC_permutation, ClauseNameLoc, OpenLoc,
CloseLoc, ArgExprs,
/*ReqIntConst=*/true))
return nullptr;
return Actions.OpenMP().ActOnOpenMPPermutationClause(ArgExprs, ClauseNameLoc,
OpenLoc, CloseLoc);
}
[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-21 13:21:00 -04: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;
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
SmallVector<SemaOpenMP::UsesAllocatorsData, 4> Data;
[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-21 13:21:00 -04:00
do {
Fix wrong error message when compiling C souce code: Currently emit error for uses_allocators(alloc(traits)): called object type 'omp_allocator_handle_t' (aka 'enum omp_allocator_handle_t') is not a function or function pointer To fix this, since "alloc" is Id expresison(spce 5.2), during the parser (in ParseOpenMP.cpp), using tryParseCXXIdExpression instead of ParseExpression for C. Differential Revision: https://reviews.llvm.org/D151517
2023-05-25 09:29:59 -07:00
CXXScopeSpec SS;
Token Replacement;
[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-14 10:04:59 -07:00
ExprResult Allocator =
Fix wrong error message when compiling C souce code: Currently emit error for uses_allocators(alloc(traits)): called object type 'omp_allocator_handle_t' (aka 'enum omp_allocator_handle_t') is not a function or function pointer To fix this, since "alloc" is Id expresison(spce 5.2), during the parser (in ParseOpenMP.cpp), using tryParseCXXIdExpression instead of ParseExpression for C. Differential Revision: https://reviews.llvm.org/D151517
2023-05-25 09:29:59 -07:00
getLangOpts().CPlusPlus
? ParseCXXIdExpression()
: tryParseCXXIdExpression(SS, /*isAddressOfOperand=*/false,
Replacement);
[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-21 13:21:00 -04:00
if (Allocator.isInvalid()) {
SkipUntil(tok::comma, tok::r_paren, tok::annot_pragma_openmp_end,
StopBeforeMatch);
break;
}
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
SemaOpenMP::UsesAllocatorsData &D = Data.emplace_back();
[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-21 13:21:00 -04:00
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-14 10:04:59 -07: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-21 13:21:00 -04: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();
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
return Actions.OpenMP().ActOnOpenMPUsesAllocatorClause(
Loc, T.getOpenLocation(), T.getCloseLocation(), Data);
[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-21 13:21:00 -04: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 01:00:01 +00:00
/// Parsing of OpenMP clauses.
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00:00
///
/// clause:
[OPENMP] Initial parsing and sema analysis for 'final' clause. llvm-svn: 213232
2014-07-17 07:32:53 +00:00
/// if-clause | final-clause | num_threads-clause | safelen-clause |
/// default-clause | private-clause | firstprivate-clause | shared-clause
[OpenMP] Add parsing/sema/serialization for 'bind' clause. Differential Revision: https://reviews.llvm.org/D113154
2021-11-03 14:57:01 -07:00
/// | linear-clause | aligned-clause | collapse-clause | bind-clause |
[OPENMP] Initial parsing and sema analysis for 'final' clause. llvm-svn: 213232
2014-07-17 07:32:53 +00:00
/// lastprivate-clause | reduction-clause | proc_bind-clause |
[OPENMP] Initial parsing and sema analysis of 'mergeable' clause. llvm-svn: 213262
2014-07-17 12:47:03 +00: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 10:25:33 +00: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 11:14:16 +00: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-27 18:47:36 +00: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 12:52:51 +00: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-26 17:49:04 +00: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-21 18:48:21 +00: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-06 16:30:23 -05: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 09:52:15 -05: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 10:41:08 -04:00
/// depobj-clause | destroy-clause | detach-clause | inclusive-clause |
[clang][OpenMP5.1] Initial parsing/sema for has_device_addr Added basic parsing/sema/ support for the 'has_device_addr' clause. Differential Revision: https://reviews.llvm.org/D123402
2022-04-06 20:30:44 -07:00
/// exclusive-clause | uses_allocators-clause | use_device_addr-clause |
/// has_device_addr
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00: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-09 13:27:32 -05:00
OMPClauseKind = CKind;
[C++11] Use 'nullptr'. Parser edition. llvm-svn: 209275
2014-05-21 06:02:52 +00:00
OMPClause *Clause = nullptr;
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00: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-09 19:21:04 +00:00
bool WrongDirective = false;
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00: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-19 12:07:54 -05: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-29 18:44:28 -05: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 03:13:43 +00: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-09 19:21:04 +00:00
WrongDirective = true;
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00:00
}
switch (CKind) {
[OPENMP] Initial parsing and sema analysis for 'final' clause. llvm-svn: 213232
2014-07-17 07:32:53 +00:00
case OMPC_final:
[OPENMP] Clause 'num_threads' llvm-svn: 203087
2014-03-06 06:15:19 +00:00
case OMPC_num_threads:
[OPENMP] parsing of clause 'safelen' (for directive 'omp simd') llvm-svn: 204428
2014-03-21 04:51:18 +00: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 11:14:16 +00: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 15:12:19 +00: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 11:36:16 +00:00
case OMPC_ordered:
[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 10:17:31 +00: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 12:52:51 +00: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 12:06:20 +00: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 08:19:24 +00: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-12 18:52:33 +00:00
case OMPC_allocator:
[OPENMP50]Add basic support for depobj construct. Added basic parsing/sema/serialization support for depobj directive.
2020-02-28 09:52:15 -05:00
case OMPC_depobj:
[OPENMP50]Initial support for detach clause in task directive. Added parsing/sema/serialization support for detach clause.
2020-03-17 09:17:42 -04:00
case OMPC_detach:
[OPENMP5.1]Initial support for novariants clause. Added basic parsing/sema/serialization support for the 'novariants' clause.
2021-03-31 12:26:47 -07: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-03 11:09:25 -07: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-09 14:00:36 -05: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-10 14:24:17 -05:00
case OMPC_partial:
Initial parsing/sema for 'align' clause Added basic parsing/sema/serialization support for 'align' clause for use with 'allocate' directive.
2021-11-09 07:33:39 -05:00
case OMPC_align:
[OPENMP5.1] Initial support for message clause.
2022-11-17 22:03:00 -08:00
case OMPC_message:
[OpenMP] Introduce the `ompx_dyn_cgroup_mem(<N>)` clause Dynamic memory allows users to allocate fast shared memory when a kernel is launched. We support a single size for all kernels via the `LIBOMPTARGET_SHARED_MEMORY_SIZE` environment variable but now we can control it per kernel invocation, hence allow computed values. Note: Only the nextgen plugins will allocate memory based on the clause, the old plugins will silently miscompile. Differential Revision: https://reviews.llvm.org/D141233
2023-01-07 16:14:48 -08:00
case OMPC_ompx_dyn_cgroup_mem:
[OPENMP] 'if' clause support (no CodeGen support) llvm-svn: 201297
2014-02-13 05:29:23 +00:00
// OpenMP [2.5, Restrictions]
[OPENMP] Clause 'num_threads' llvm-svn: 203087
2014-03-06 06:15:19 +00: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 04:51:18 +00: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 15:12:19 +00: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 11:14:16 +00: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 15:12:19 +00: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 07:32:53 +00: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-24 20:50:12 +00: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-27 18:47:36 +00: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 10:17:31 +00: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 12:52:51 +00: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 12:06:20 +00: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-12 18:52:33 +00: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 09:17:42 -04: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-03-31 12:26:47 -07: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-03 11:09:25 -07:00
// At most one nocontext clause can appear on a dispatch directive.
[OPENMP5.1] Initial support for message clause.
2022-11-17 22:03:00 -08:00
// OpenMP [5.1, error directive, Restrictions]
// At most one message clause can appear on the directive
[OPENMP] 'if' clause support (no CodeGen support) llvm-svn: 201297
2014-02-13 05:29:23 +00: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 07:23:48 +00: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 07:46:59 +00:00
ErrorFound = true;
[OPENMP] 'if' clause support (no CodeGen support) llvm-svn: 201297
2014-02-13 05:29:23 +00: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-10 14:24:17 -05: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-09 19:21:04 +00:00
Clause = ParseOpenMPClause(CKind, WrongDirective);
[OpenMP] Initial parsing/sema for 'strict' modifier with 'num_tasks' clause This patch gives basic parsing and semantic analysis support for 'strict' modifier with 'num_tasks' clause of 'taskloop' construct introduced in OpenMP 5.1 (section 2.12.2) Differential Revision: https://reviews.llvm.org/D138328
2022-11-18 15:21:49 -08:00
else if (CKind == OMPC_grainsize || CKind == OMPC_num_tasks)
[OpenMP] Initial parsing/sema for 'strict' modifier with 'grainsize' clause This patch gives basic parsing and semantic analysis support for 'strict' modifier with 'grainsize' clause of 'taskloop' construct introduced in OpenMP 5.1 (section 2.12.2) Differential Revision: https://reviews.llvm.org/D138217
2022-11-17 16:20:14 -08:00
Clause = ParseOpenMPSingleExprWithArgClause(DKind, 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 11:36:16 +00: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-09 19:21:04 +00:00
Clause = ParseOpenMPSingleExprClause(CKind, WrongDirective);
[OPENMP] 'if' clause support (no CodeGen support) llvm-svn: 201297
2014-02-13 05:29:23 +00:00
break;
[OpenMP] atomic compare fail : Parser & AST support Diff Revision: https://reviews.llvm.org/D123235
2023-11-26 13:33:36 -06:00
case OMPC_fail:
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00:00
case OMPC_default:
[OPENMP] 'proc_bind' clause support - Parsing and sema analysis for OpenMP clause 'proc_bind' llvm-svn: 208060
2014-05-06 06:04:14 +00: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 12:18:11 +00:00
case OMPC_atomic_default_mem_order:
[OPENMP]Initial support for at clause Error directive is allowed in both declared and executable contexts. The function ActOnOpenMPAtClause is called in both places during the parsers. Adding a param "bool InExContext" to identify context which is used to emit error massage. Differential Revision: https://reviews.llvm.org/D137851
2022-11-10 18:12:35 -08:00
case OMPC_at:
[OPENMP5.1] Initial support for severity clause Differential Revision:https://reviews.llvm.org/D138227
2022-11-16 13:29:14 -08:00
case OMPC_severity:
[OpenMP] Add parsing/sema/serialization for 'bind' clause. Differential Revision: https://reviews.llvm.org/D113154
2021-11-03 14:57:01 -07:00
case OMPC_bind:
[OPENMP] 'if' clause support (no CodeGen support) llvm-svn: 201297
2014-02-13 05:29:23 +00: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 06:04:14 +00: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 12:18:11 +00:00
// OpenMP [5.0, Requires directive, Restrictions]
// At most one atomic_default_mem_order clause can appear
// on the directive
[OPENMP5.1] Initial support for severity clause Differential Revision:https://reviews.llvm.org/D138227
2022-11-16 13:29:14 -08:00
// OpenMP [5.1, error directive, Restrictions]
[OPENMP]Initial support for at clause Error directive is allowed in both declared and executable contexts. The function ActOnOpenMPAtClause is called in both places during the parsers. Adding a param "bool InExContext" to identify context which is used to emit error massage. Differential Revision: https://reviews.llvm.org/D137851
2022-11-10 18:12:35 -08:00
// At most one at clause can appear on the directive
[OPENMP5.1] Initial support for severity clause Differential Revision:https://reviews.llvm.org/D138227
2022-11-16 13:29:14 -08:00
// At most one severity clause can appear on the directive
[OpenMP] Add parsing/sema/serialization for 'bind' clause. Differential Revision: https://reviews.llvm.org/D113154
2021-11-03 14:57:01 -07:00
// OpenMP 5.1, 2.11.7 loop Construct, Restrictions.
// At most one bind clause can appear on a loop directive.
[OpenMP] Basic parse and sema support for modifiers in order clause This patch gives basic parsing and semantic support for "modifiers" of order clause introduced in OpenMP 5.1 ( section 2.11.3 ) Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D127855
2022-12-12 15:51:38 -06: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 07:23:48 +00: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 07:46:59 +00:00
ErrorFound = true;
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00: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-09 19:21:04 +00:00
Clause = ParseOpenMPSimpleClause(CKind, WrongDirective);
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00: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-18 15:01:15 -04:00
case OMPC_device:
[OPENMP] Initial support for 'schedule' clause. llvm-svn: 211342
2014-06-20 07:16:17 +00:00
case OMPC_schedule:
Add OpenMP dist_schedule clause to distribute directive and related regression tests. llvm-svn: 257917
2016-01-15 18:50:31 +00: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-26 16:37:23 +00:00
case OMPC_defaultmap:
[OpenMP] Basic parse and sema support for modifiers in order clause This patch gives basic parsing and semantic support for "modifiers" of order clause introduced in OpenMP 5.1 ( section 2.11.3 ) Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D127855
2022-12-12 15:51:38 -06:00
case OMPC_order:
[OPENMP] Initial support for 'schedule' clause. llvm-svn: 211342
2014-06-20 07:16:17 +00: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-15 13:02:06 -05: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-26 16:37:23 +00: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-18 15:01:15 -04:00
// OpenMP 5.0 [2.12.5, target construct, Restrictions]
// At most one device clause can appear on the directive.
[OpenMP] Basic parse and sema support for modifiers in order clause This patch gives basic parsing and semantic support for "modifiers" of order clause introduced in OpenMP 5.1 ( section 2.11.3 ) Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D127855
2022-12-12 15:51:38 -06:00
// OpenMP 5.1 [2.11.3, order clause, Restrictions]
// At most one order clause may appear on a construct.
[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-15 13:02:06 -05:00
if ((getLangOpts().OpenMP < 50 || CKind != OMPC_defaultmap) &&
[OpenMP] Basic parse and sema support for modifiers in order clause This patch gives basic parsing and semantic support for "modifiers" of order clause introduced in OpenMP 5.1 ( section 2.11.3 ) Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D127855
2022-12-12 15:51:38 -06:00
(CKind != OMPC_order || getLangOpts().OpenMP >= 51) && !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 07:23:48 +00: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 07:46:59 +00:00
ErrorFound = true;
[OPENMP] Initial support for 'schedule' clause. llvm-svn: 211342
2014-06-20 07:16:17 +00:00
}
[clang] LLVM_FALLTHROUGH => [[fallthrough]]. NFC With C++17 there is no Clang pedantic warning or MSVC C5051. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D131346
2022-08-08 09:12:46 -07:00
[[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 07:23:48 +00: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-18 15:01:15 -04:00
Clause = ParseOpenMPSingleExprWithArgClause(DKind, CKind, WrongDirective);
[OPENMP] Initial support for 'schedule' clause. llvm-svn: 211342
2014-06-20 07:16:17 +00:00
break;
[OpenMP] OpenMP 5.1 "assume" directive parsing support (#92731) This is a minimal patch to support parsing for "omp assume" directives. These are meant to be hints to a compiler's optimisers: as such, it is legitimate (if not very useful) to ignore them. The patch builds on top of the existing support for "omp assumes" directives (note spelling!). Unlike the "omp [begin/end] assumes" directives, "omp assume" is associated with a compound statement, i.e. it can appear within a function. The "holds" assumption could (theoretically) be mapped onto the existing builtin "__builtin_assume", though the latter applies to a single point in the program, and the former to a range (i.e. the whole of the associated compound statement). This patch fixes sollve's OpenMP 5.1 "omp assume"-based tests.
2024-08-05 12:37:07 +01:00
case OMPC_holds:
Clause = ParseOpenMPSingleExprClause(CKind, WrongDirective);
break;
[OPENMP] Initial support for 'nowait' clause. llvm-svn: 211352
2014-06-20 11:19:47 +00:00
case OMPC_nowait:
[OPENMP] Initial support for parsing and sema analysis of 'untied' clause. llvm-svn: 213257
2014-07-17 12:19:31 +00:00
case OMPC_untied:
[OPENMP] Initial parsing and sema analysis of 'mergeable' clause. llvm-svn: 213262
2014-07-17 12:47:03 +00:00
case OMPC_mergeable:
[OPENMP] Initial parsing and sema analysis for 'read' clause in 'atomic' directive. llvm-svn: 213717
2014-07-23 02:27:21 +00:00
case OMPC_read:
[OPENMP] Initial parsing an sema analysis for 'write' clause of 'atomic' directive. llvm-svn: 213728
2014-07-23 07:46:59 +00:00
case OMPC_write:
[OPENMP] Initial parsing and sema analysis for clause 'capture' in 'atomic' directive. llvm-svn: 213842
2014-07-24 06:46:57 +00:00
case OMPC_capture:
[Clang][OpenMP] Add the support for atomic compare in parser This patch adds the support for `atomic compare` in parser. The support in Sema and CodeGen will come soon. For now, it simply eimits an error when it is encountered. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D115561
2021-12-24 08:16:33 -05:00
case OMPC_compare:
[OPENMP] Initial parsing and sema analysis for clause 'seq_cst' of 'atomic' directive. llvm-svn: 213846
2014-07-24 08:55:34 +00: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-06 16:30:23 -05:00
case OMPC_acq_rel:
[OPENMP50]Support for acquire clause. Added full support for acquire clause in flush|atomic directives.
2020-02-10 14:30:39 -05:00
case OMPC_acquire:
[OPENMP50]Add support for 'release' clause. Added full support for 'release' clause in flush|atomic directives.
2020-02-10 15:49:05 -05:00
case OMPC_release:
[OPENMP50]Add support for relaxed clause in atomic directive. Added full support for relaxed clause.
2020-02-11 11:10:43 -05:00
case OMPC_relaxed:
[OpenMP] atomic compare weak : Parser & AST support (#79475) This is a support for " #pragma omp atomic compare weak". It has Parser & AST support for now. --------- Authored-by: Sunil Kuravinakop <kuravina@pe28vega.us.cray.com>
2024-01-31 17:02:06 +05:30
case OMPC_weak:
[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 10:37:12 +00: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 06:39:35 +00: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 10:51:44 +00: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 04:28:39 +00:00
case OMPC_unified_address:
Add support for unified_shared_memory clause on requires directive llvm-svn: 343472
2018-10-01 13:47:43 +00:00
case OMPC_unified_shared_memory:
[OPENMP] Add reverse_offload clause to requires directive llvm-svn: 343711
2018-10-03 20:07:58 +00: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 14:41:10 +00: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-10 14:24:17 -05:00
case OMPC_full:
[OPENMP] Initial support for 'ordered' clause. llvm-svn: 211347
2014-06-20 09:44:06 +00: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 11:19:47 +00: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 04:28:39 +00: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 09:44:06 +00: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 07:23:48 +00: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 07:46:59 +00:00
ErrorFound = true;
[OPENMP] Initial support for 'ordered' clause. llvm-svn: 211347
2014-06-20 09:44:06 +00:00
}
[clang] [OpenMP] New OpenMP 6.0 self_maps clause (#129888) Initial parsing/sema support for self maps in map and requirement clause [Sections 7.9.6 and 10.5.1.6 in OpenMP 6.0 spec]
2025-03-11 16:31:42 +05:30
Clause = ParseOpenMPClause(CKind, WrongDirective);
break;
case OMPC_self_maps:
// OpenMP [6.0, self_maps clause]
if (getLangOpts().OpenMP < 60) {
Diag(Tok, diag::err_omp_expected_clause)
<< getOpenMPDirectiveName(OMPD_requires);
ErrorFound = true;
}
if (!FirstClause) {
Diag(Tok, diag::err_omp_more_one_clause)
<< getOpenMPDirectiveName(DKind) << getOpenMPClauseName(CKind) << 0;
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-09 19:21:04 +00:00
Clause = ParseOpenMPClause(CKind, WrongDirective);
[OPENMP] Initial support for 'ordered' clause. llvm-svn: 211347
2014-06-20 09:44:06 +00:00
break;
[OPENMP50]Support 'update' clause for 'depobj' directive. Added basic support (parsing/sema/serialization) for 'update' clause in 'depobj' directive.
2020-03-03 13:22:35 -05: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;
[Clang][Sema][OpenMP] Allow `num_teams` to accept multiple expressions (#99732) By the OpenMP standard, `num_teams` clause can only accept one expression (for now). In this patch, we extend it to allow to accept multiple expressions when it is used with `target teams ompx_bare` construct. This will allow to launch a multi-dim grid, same as CUDA/HIP.
2024-08-06 10:55:15 -04:00
case OMPC_num_teams:
[Clang][Sema][OpenMP] Allow `thread_limit` to accept multiple expressions (#102715)
2024-08-10 09:54:58 -04:00
case OMPC_thread_limit:
[Clang][Sema][OpenMP] Allow `num_teams` to accept multiple expressions (#99732) By the OpenMP standard, `num_teams` clause can only accept one expression (for now). In this patch, we extend it to allow to accept multiple expressions when it is used with `target teams ompx_bare` construct. This will allow to launch a multi-dim grid, same as CUDA/HIP.
2024-08-06 10:55:15 -04:00
if (!FirstClause) {
Diag(Tok, diag::err_omp_more_one_clause)
<< getOpenMPDirectiveName(DKind) << getOpenMPClauseName(CKind) << 0;
ErrorFound = true;
}
[NFC] Fix compile warning introduced in #99732
2024-08-06 12:45:29 -04:00
[[fallthrough]];
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00:00
case OMPC_private:
[OpenMP] Added parsing and semantic analysis for firstprivate clause llvm-svn: 191730
2013-10-01 05:32:34 +00: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 13:06:39 +00:00
case OMPC_lastprivate:
OpenMP: Data-sharing attributes analysis and clause 'shared' (fixed test threadprivate_messages.cpp) llvm-svn: 190183
2013-09-06 18:03:48 +00:00
case OMPC_shared:
[OPENMP] Initial support of 'reduction' clause llvm-svn: 211007
2014-06-16 07:08:35 +00:00
case OMPC_reduction:
[OPENMP] Initial support for 'task_reduction' clause. Parsing/sema analysis of the 'task_reduction' clause. llvm-svn: 308352
2017-07-18 20:17:46 +00: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-21 18:48:21 +00: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 13:09:42 +00:00
case OMPC_linear:
Parsing/Sema for OMPAlignedClause. llvm-svn: 209816
2014-05-29 14:36:25 +00:00
case OMPC_aligned:
[OPENMP] Implemented 'copyin' clause llvm-svn: 205164
2014-03-31 03:36:38 +00:00
case OMPC_copyin:
[OPENMP] Parsing and sema analysis for 'copyprivate' clause. llvm-svn: 211886
2014-06-27 10:37:06 +00:00
case OMPC_copyprivate:
[OPENMP] Initial parsing and sema analysis for 'flush' directive. llvm-svn: 213512
2014-07-21 11:26:11 +00: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 14:25:19 +00:00
case OMPC_depend:
[OpenMP] Parsing and sema support for map clause http://reviews.llvm.org/D14134 llvm-svn: 253849
2015-11-23 05:32:03 +00: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-26 17:39:58 +00: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-26 17:49:04 +00: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 15:37:16 +00: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 08:30:23 -04: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-13 17:16:49 +00:00
case OMPC_is_device_ptr:
[clang][OpenMP5.1] Initial parsing/sema for has_device_addr Added basic parsing/sema/ support for the 'has_device_addr' clause. Differential Revision: https://reviews.llvm.org/D123402
2022-04-06 20:30:44 -07:00
case OMPC_has_device_addr:
[OPENMP]Initial support for 'allocate' clause. Added parsing/sema analysis of the allocate clause. llvm-svn: 357068
2019-03-27 14:14:31 +00: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-16 15:54:17 -05:00
case OMPC_nontemporal:
[OPENMP50]Initial support for inclusive clause. Added parsing/sema/serialization support for inclusive clause in scan directive.
2020-03-20 09:41:22 -04: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 10:41:08 -04: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-18 13:37:53 -04:00
case OMPC_affinity:
[OMP5.2] Initial support for doacross clause.
2023-06-21 16:26:35 -07:00
case OMPC_doacross:
[flang][OpenMP] Add semantic check for declare target (#72770)
2023-11-22 16:13:14 -06:00
case OMPC_enter:
[OPENMP52] Deprecation of 'depend' clause in ordered directive. BTW, I need change test ordered_doacross_codegen.c since I can not use macro _OPENMP >= 202111 due to use of -fopenmp-simd. Differential Revision: https://reviews.llvm.org/D154672
2023-07-06 17:55:42 -07:00
if (getLangOpts().OpenMP >= 52 && DKind == OMPD_ordered &&
CKind == OMPC_depend)
Diag(Tok, diag::warn_omp_depend_in_ordered_deprecated);
[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-09 19:21:04 +00:00
Clause = ParseOpenMPVarListClause(DKind, CKind, WrongDirective);
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00: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-12 11: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;
[Clang][OpenMP] Add permutation clause (#92030) Add the permutation clause for the interchange directive which will be introduced in the upcoming OpenMP 6.0 specification. A preview has been published in [Technical Report12](https://www.openmp.org/wp-content/uploads/openmp-TR12.pdf).
2024-10-09 14:56:43 +02:00
case OMPC_permutation:
if (!FirstClause) {
Diag(Tok, diag::err_omp_more_one_clause)
<< getOpenMPDirectiveName(DKind) << getOpenMPClauseName(CKind) << 0;
ErrorFound = true;
}
Clause = ParseOpenMPPermutationClause();
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-21 13:21:00 -04: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-17 16:43:47 -07: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;
}
[clang] LLVM_FALLTHROUGH => [[fallthrough]]. NFC With C++17 there is no Clang pedantic warning or MSVC C5051. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D131346
2022-08-08 09:12:46 -07:00
[[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-15 13:09:46 -07: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-17 13:04:08 -07: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-15 13:09:46 -07: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-23 16:11:14 +00:00
case OMPC_device_type:
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00: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-21 13:48:56 -06:00
skipUntilPragmaOpenMPEnd(DKind);
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00: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 05:28:34 +00: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-23 18:13:31 +00: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-09 19:21:04 +00: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-18 19:10:49 +00:00
SkipUntil(tok::comma, tok::annot_pragma_openmp_end, StopBeforeMatch);
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00:00
break;
[OpenMP] OpenMP 5.1 "assume" directive parsing support (#92731) This is a minimal patch to support parsing for "omp assume" directives. These are meant to be hints to a compiler's optimisers: as such, it is legitimate (if not very useful) to ignore them. The patch builds on top of the existing support for "omp assumes" directives (note spelling!). Unlike the "omp [begin/end] assumes" directives, "omp assume" is associated with a compound statement, i.e. it can appear within a function. The "holds" assumption could (theoretically) be mapped onto the existing builtin "__builtin_assume", though the latter applies to a single point in the program, and the former to a range (i.e. the whole of the associated compound statement). This patch fixes sollve's OpenMP 5.1 "omp assume"-based tests.
2024-08-05 12:37:07 +01:00
case OMPC_absent:
case OMPC_contains: {
SourceLocation Loc = ConsumeToken();
SourceLocation LLoc = Tok.getLocation();
SourceLocation RLoc;
llvm::SmallVector<OpenMPDirectiveKind, 4> DKVec;
BalancedDelimiterTracker T(*this, tok::l_paren);
T.consumeOpen();
do {
OpenMPDirectiveKind DK = getOpenMPDirectiveKind(PP.getSpelling(Tok));
if (DK == OMPD_unknown) {
skipUntilPragmaOpenMPEnd(OMPD_assume);
Diag(Tok, diag::err_omp_unexpected_clause)
<< getOpenMPClauseName(CKind) << getOpenMPDirectiveName(DKind);
break;
}
if (isOpenMPExecutableDirective(DK)) {
DKVec.push_back(DK);
ConsumeToken();
} else {
Diag(Tok, diag::err_omp_unexpected_clause)
<< getOpenMPClauseName(CKind) << getOpenMPDirectiveName(DKind);
}
} while (TryConsumeToken(tok::comma));
RLoc = Tok.getLocation();
T.consumeClose();
Clause = Actions.OpenMP().ActOnOpenMPDirectivePresenceClause(
CKind, DKVec, Loc, LLoc, RLoc);
break;
}
case OMPC_no_openmp:
case OMPC_no_openmp_routines:
[clang][OpenMP] New OpenMP 6.0 assumption clause, 'no_openmp_constructs' (#125933) Add initial parsing/sema support for new assumption clause so clause can be specified. For now, it's ignored, just like the others. Added support for 'no_openmp_construct' to release notes. Testing - Updated appropriate LIT tests. - Testing: check-all
2025-02-06 12:41:10 -08:00
case OMPC_no_openmp_constructs:
[OpenMP] OpenMP 5.1 "assume" directive parsing support (#92731) This is a minimal patch to support parsing for "omp assume" directives. These are meant to be hints to a compiler's optimisers: as such, it is legitimate (if not very useful) to ignore them. The patch builds on top of the existing support for "omp assumes" directives (note spelling!). Unlike the "omp [begin/end] assumes" directives, "omp assume" is associated with a compound statement, i.e. it can appear within a function. The "holds" assumption could (theoretically) be mapped onto the existing builtin "__builtin_assume", though the latter applies to a single point in the program, and the former to a range (i.e. the whole of the associated compound statement). This patch fixes sollve's OpenMP 5.1 "omp assume"-based tests.
2024-08-05 12:37:07 +01:00
case OMPC_no_parallelism: {
if (!FirstClause) {
Diag(Tok, diag::err_omp_more_one_clause)
<< getOpenMPDirectiveName(DKind) << getOpenMPClauseName(CKind) << 0;
ErrorFound = true;
}
SourceLocation Loc = ConsumeToken();
Clause = Actions.OpenMP().ActOnOpenMPNullaryAssumptionClause(
CKind, Loc, Tok.getLocation());
break;
}
Reapply "[OpenMP] Add the `ompx_attribute` clause for target directives" This reverts commit 0d12683046ca75fb08e285f4622f2af5c82609dc and reapplies ef9ec4bbcca2fa4f64df47bc426f1d1c59ea47e2 with an extension to fix the Flang build. Differential Revision: https://reviews.llvm.org/D156184
2023-07-25 09:37:49 -07:00
case OMPC_ompx_attribute:
Clause = ParseOpenMPOMPXAttributesClause(WrongDirective);
break;
Introduce the initial support for OpenMP kernel language (#66844) This patch starts the support for OpenMP kernel language, basically to write OpenMP target region in SIMT style, similar to kernel languages such as CUDA. What included in this first patch is the `ompx_bare` clause for `target teams` directive. When `ompx_bare` exists, globalization is disabled such that local variables will not be globalized. The runtime init/deinit function calls will not be emitted. That being said, almost all OpenMP executable directives are not supported in the region, such as parallel, task. This patch doesn't include the Sema checks for that, so the use of them is UB. Simple directives, such as atomic, can be used. We provide a set of APIs (for C, they are prefix with `ompx_`; for C++, they are in `ompx` namespace) to get thread id, block id, etc. Please refer to https://tianshilei.me/wp-content/uploads/llvm-hpc-2023.pdf for more details.
2023-10-05 17:34:40 -04:00
case OMPC_ompx_bare:
[flang][OpenMP] Add frontend support for ompx_bare clause (#111106)
2024-12-13 21:44:43 +09:00
if (DKind == llvm::omp::Directive::OMPD_target) {
// Flang splits the combined directives which requires OMPD_target to be
// marked as accepting the `ompx_bare` clause in `OMP.td`. Thus, we need
// to explicitly check whether this clause is applied to an `omp target`
// without `teams` and emit an error.
Diag(Tok, diag::err_omp_unexpected_clause)
<< getOpenMPClauseName(CKind) << getOpenMPDirectiveName(DKind);
ErrorFound = true;
WrongDirective = true;
}
Introduce the initial support for OpenMP kernel language (#66844) This patch starts the support for OpenMP kernel language, basically to write OpenMP target region in SIMT style, similar to kernel languages such as CUDA. What included in this first patch is the `ompx_bare` clause for `target teams` directive. When `ompx_bare` exists, globalization is disabled such that local variables will not be globalized. The runtime init/deinit function calls will not be emitted. That being said, almost all OpenMP executable directives are not supported in the region, such as parallel, task. This patch doesn't include the Sema checks for that, so the use of them is UB. Simple directives, such as atomic, can be used. We provide a set of APIs (for C, they are prefix with `ompx_`; for C++, they are in `ompx` namespace) to get thread id, block id, etc. Please refer to https://tianshilei.me/wp-content/uploads/llvm-hpc-2023.pdf for more details.
2023-10-05 17:34:40 -04:00
if (WrongDirective)
Diag(Tok, diag::note_ompx_bare_clause)
<< getOpenMPClauseName(CKind) << "target teams";
if (!ErrorFound && !getLangOpts().OpenMPExtensions) {
Diag(Tok, diag::err_omp_unexpected_clause_extension_only)
<< getOpenMPClauseName(CKind) << getOpenMPDirectiveName(DKind);
ErrorFound = true;
}
Clause = ParseOpenMPClause(CKind, WrongDirective);
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-01 20:57:11 -04:00
default:
break;
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00:00
}
[C++11] Use 'nullptr'. Parser edition. llvm-svn: 209275
2014-05-21 06:02:52 +00:00
return ErrorFound ? nullptr : Clause;
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00: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 12:45:37 +00: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-13 20:18:17 +00: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 12:45:37 +00: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-29 18:44:28 -05: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 12:45:37 +00: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-04 16:58:14 +00: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 12:45:37 +00: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-06 19:35:42 +00: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 12:45:37 +00: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 01:00:01 +00: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 10:17:31 +00: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 09:17:42 -04:00
/// 'thread_limit', 'simdlen', 'priority', 'grainsize', 'num_tasks', 'hint' or
/// 'detach'.
[OPENMP] 'if' clause support (no CodeGen support) llvm-svn: 201297
2014-02-13 05:29:23 +00:00
///
[OPENMP] Initial parsing and sema analysis for 'final' clause. llvm-svn: 213232
2014-07-17 07:32:53 +00:00
/// final-clause:
/// 'final' '(' expression ')'
///
[OPENMP] parsing of clause 'safelen' (for directive 'omp simd') llvm-svn: 204428
2014-03-21 04:51:18 +00: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 11:14:16 +00: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 15:12:19 +00: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 10:17:31 +00: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 12:52:51 +00: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 12:06:20 +00: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 08:19:24 +00: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-12 18:52:33 +00: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 09:17:42 -04:00
/// detach-clause:
/// 'detach' '(' event-handler-expression ')'
///
Initial parsing/sema for 'align' clause Added basic parsing/sema/serialization support for 'align' clause for use with 'allocate' directive.
2021-11-09 07:33:39 -05:00
/// align-clause
/// 'align' '(' positive-integer-constant ')'
///
[OpenMP] OpenMP 5.1 "assume" directive parsing support (#92731) This is a minimal patch to support parsing for "omp assume" directives. These are meant to be hints to a compiler's optimisers: as such, it is legitimate (if not very useful) to ignore them. The patch builds on top of the existing support for "omp assumes" directives (note spelling!). Unlike the "omp [begin/end] assumes" directives, "omp assume" is associated with a compound statement, i.e. it can appear within a function. The "holds" assumption could (theoretically) be mapped onto the existing builtin "__builtin_assume", though the latter applies to a single point in the program, and the former to a range (i.e. the whole of the associated compound statement). This patch fixes sollve's OpenMP 5.1 "omp assume"-based tests.
2024-08-05 12:37:07 +01:00
/// holds-clause
/// 'holds' '(' 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-09 19:21:04 +00:00
OMPClause *Parser::ParseOpenMPSingleExprClause(OpenMPClauseKind Kind,
bool ParseOnly) {
[OPENMP] 'if' clause support (no CodeGen support) llvm-svn: 201297
2014-02-13 05:29:23 +00: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 12:45:37 +00:00
SourceLocation LLoc = Tok.getLocation();
SourceLocation RLoc;
[OPENMP] 'if' clause support (no CodeGen support) llvm-svn: 201297
2014-02-13 05:29:23 +00: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 12:45:37 +00:00
ExprResult Val = ParseOpenMPParensExpr(getOpenMPClauseName(Kind), RLoc);
[OPENMP] 'if' clause support (no CodeGen support) llvm-svn: 201297
2014-02-13 05:29:23 +00:00
if (Val.isInvalid())
[C++11] Use 'nullptr'. Parser edition. llvm-svn: 209275
2014-05-21 06:02:52 +00:00
return nullptr;
[OPENMP] 'if' clause support (no CodeGen support) llvm-svn: 201297
2014-02-13 05:29:23 +00: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-09 19:21:04 +00:00
if (ParseOnly)
return nullptr;
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
return Actions.OpenMP().ActOnOpenMPSingleExprClause(Kind, Val.get(), Loc,
LLoc, RLoc);
[OPENMP] 'if' clause support (no CodeGen support) llvm-svn: 201297
2014-02-13 05:29:23 +00:00
}
[clang][OpenMP5.1] Initial parsing/sema for 'indirect' clause Differential Revision: https://reviews.llvm.org/D116764
2022-01-10 16:20:02 -08:00
/// Parse indirect clause for '#pragma omp declare target' directive.
/// 'indirect' '[' '(' invoked-by-fptr ')' ']'
/// where invoked-by-fptr is a constant boolean expression that evaluates to
/// true or false at compile time.
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
bool Parser::ParseOpenMPIndirectClause(
SemaOpenMP::DeclareTargetContextInfo &DTCI, bool ParseOnly) {
[clang][OpenMP5.1] Initial parsing/sema for 'indirect' clause Differential Revision: https://reviews.llvm.org/D116764
2022-01-10 16:20:02 -08:00
SourceLocation Loc = ConsumeToken();
SourceLocation RLoc;
if (Tok.isNot(tok::l_paren)) {
if (ParseOnly)
return false;
DTCI.Indirect = nullptr;
return true;
}
ExprResult Val =
ParseOpenMPParensExpr(getOpenMPClauseName(OMPC_indirect), RLoc);
if (Val.isInvalid())
return false;
if (ParseOnly)
return false;
if (!Val.get()->isValueDependent() && !Val.get()->isTypeDependent() &&
!Val.get()->isInstantiationDependent() &&
!Val.get()->containsUnexpandedParameterPack()) {
ExprResult Ret = Actions.CheckBooleanCondition(Loc, Val.get());
if (Ret.isInvalid())
return false;
llvm::APSInt Result;
Ret = Actions.VerifyIntegerConstantExpression(Val.get(), &Result,
Sema::AllowFold);
if (Ret.isInvalid())
return false;
DTCI.Indirect = Val.get();
return true;
}
return false;
}
[OpenMP][NFC] Refactor code for interop parts of 'init' and 'append_args' clauses The 'init' clause allows an interop-modifier of prefer_type(list) and and interop-types 'target' and 'targetsync'. The 'append_args' clause uses an append-op that also includes interop-types ('target' and 'targetsync') and will allow a prefer_type list in the next OpenMP version. This change adds a helper struct OMPInteropInfo and uses it in the parsing of both the 'init' and 'append_args' clauses. One OMPInteropInfo object represents the info in a single 'init' clause. Since 'append_args' allows a variable number of interop items it will require an array of OMPInteropInfo objects once that is supported. Differential Revision: https://reviews.llvm.org/D132171
2022-08-18 11:54:52 -07:00
/// Parses a comma-separated list of interop-types and a prefer_type list.
///
bool Parser::ParseOMPInteropInfo(OMPInteropInfo &InteropInfo,
OpenMPClauseKind Kind) {
const Token &Tok = getCurToken();
bool HasError = false;
bool IsTarget = false;
bool IsTargetSync = false;
while (Tok.is(tok::identifier)) {
// Currently prefer_type is only allowed with 'init' and it must be first.
bool PreferTypeAllowed = Kind == OMPC_init &&
InteropInfo.PreferTypes.empty() && !IsTarget &&
!IsTargetSync;
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)
Diag(Tok, diag::warn_omp_more_one_interop_type) << "target";
IsTarget = true;
ConsumeToken();
} else if (Tok.getIdentifierInfo()->isStr("targetsync")) {
if (IsTargetSync)
Diag(Tok, diag::warn_omp_more_one_interop_type) << "targetsync";
IsTargetSync = true;
ConsumeToken();
} else if (Tok.getIdentifierInfo()->isStr("prefer_type") &&
PreferTypeAllowed) {
ConsumeToken();
BalancedDelimiterTracker PT(*this, tok::l_paren,
tok::annot_pragma_openmp_end);
if (PT.expectAndConsume(diag::err_expected_lparen_after, "prefer_type"))
HasError = true;
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()) {
InteropInfo.PreferTypes.push_back(PTExpr.get());
} else {
HasError = true;
SkipUntil(tok::comma, tok::r_paren, tok::annot_pragma_openmp_end,
StopBeforeMatch);
}
if (Tok.is(tok::comma))
ConsumeToken();
}
PT.consumeClose();
} else {
HasError = true;
Diag(Tok, diag::err_omp_expected_interop_type);
ConsumeToken();
}
if (!Tok.is(tok::comma))
break;
ConsumeToken();
}
if (!HasError && !IsTarget && !IsTargetSync) {
Diag(Tok, diag::err_omp_expected_interop_type);
HasError = true;
}
if (Kind == OMPC_init) {
if (Tok.isNot(tok::colon) && (IsTarget || IsTargetSync))
Diag(Tok, diag::warn_pragma_expected_colon) << "interop types";
if (Tok.is(tok::colon))
ConsumeToken();
}
// As of OpenMP 5.1,there are two interop-types, "target" and
// "targetsync". Either or both are allowed for a single interop.
InteropInfo.IsTarget = IsTarget;
InteropInfo.IsTargetSync = IsTargetSync;
return HasError;
}
[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-15 13:09:46 -07: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;
[OpenMP][NFC] Refactor code for interop parts of 'init' and 'append_args' clauses The 'init' clause allows an interop-modifier of prefer_type(list) and and interop-types 'target' and 'targetsync'. The 'append_args' clause uses an append-op that also includes interop-types ('target' and 'targetsync') and will allow a prefer_type list in the next OpenMP version. This change adds a helper struct OMPInteropInfo and uses it in the parsing of both the 'init' and 'append_args' clauses. One OMPInteropInfo object represents the info in a single 'init' clause. Since 'append_args' allows a variable number of interop items it will require an array of OMPInteropInfo objects once that is supported. Differential Revision: https://reviews.llvm.org/D132171
2022-08-18 11:54:52 -07:00
bool InteropError = false;
OMPInteropInfo InteropInfo;
if (Kind == OMPC_init)
InteropError = ParseOMPInteropInfo(InteropInfo, OMPC_init);
[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-15 13:09:46 -07:00
// 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();
[OpenMP][NFC] Refactor code for interop parts of 'init' and 'append_args' clauses The 'init' clause allows an interop-modifier of prefer_type(list) and and interop-types 'target' and 'targetsync'. The 'append_args' clause uses an append-op that also includes interop-types ('target' and 'targetsync') and will allow a prefer_type list in the next OpenMP version. This change adds a helper struct OMPInteropInfo and uses it in the parsing of both the 'init' and 'append_args' clauses. One OMPInteropInfo object represents the info in a single 'init' clause. Since 'append_args' allows a variable number of interop items it will require an array of OMPInteropInfo objects once that is supported. Differential Revision: https://reviews.llvm.org/D132171
2022-08-18 11:54:52 -07:00
if (ParseOnly || !InteropVarExpr.isUsable() || InteropError)
[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-15 13:09:46 -07:00
return nullptr;
if (Kind == OMPC_init)
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
return Actions.OpenMP().ActOnOpenMPInitClause(
InteropVarExpr.get(), InteropInfo, 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-17 13:04:08 -07:00
if (Kind == OMPC_use)
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
return Actions.OpenMP().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-15 13:09:46 -07: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-17 16:43:47 -07:00
if (Kind == OMPC_destroy)
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
return Actions.OpenMP().ActOnOpenMPDestroyClause(
InteropVarExpr.get(), Loc, T.getOpenLocation(), VarLoc, RLoc);
[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-17 16:43:47 -07: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-15 13:09:46 -07:00
llvm_unreachable("Unexpected interop variable clause.");
}
Reapply "[OpenMP] Add the `ompx_attribute` clause for target directives" This reverts commit 0d12683046ca75fb08e285f4622f2af5c82609dc and reapplies ef9ec4bbcca2fa4f64df47bc426f1d1c59ea47e2 with an extension to fix the Flang build. Differential Revision: https://reviews.llvm.org/D156184
2023-07-25 09:37:49 -07:00
OMPClause *Parser::ParseOpenMPOMPXAttributesClause(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(OMPC_ompx_attribute).data()))
return nullptr;
ParsedAttributes ParsedAttrs(AttrFactory);
ParseAttributes(PAKM_GNU | PAKM_CXX11, ParsedAttrs);
// Parse ')'.
if (T.consumeClose())
return nullptr;
if (ParseOnly)
return nullptr;
SmallVector<Attr *> Attrs;
for (const ParsedAttr &PA : ParsedAttrs) {
switch (PA.getKind()) {
case ParsedAttr::AT_AMDGPUFlatWorkGroupSize:
if (!PA.checkExactlyNumArgs(Actions, 2))
continue;
[clang] Introduce target-specific `Sema` components (#93179) This patch introduces `SemaAMDGPU`, `SemaARM`, `SemaBPF`, `SemaHexagon`, `SemaLoongArch`, `SemaMIPS`, `SemaNVPTX`, `SemaPPC`, `SemaSystemZ`, `SemaWasm`. This continues previous efforts to split Sema up. Additional context can be found in #84184 and #92682. I decided to bundle target-specific components together because of their low impact on `Sema`. That said, their impact on `SemaChecking.cpp` is far from low, and I consider it a success. Somewhat accidentally, I also moved Wasm- and AMDGPU-specific function from `SemaDeclAttr.cpp`, because they were exposed in `Sema`. That went well, and I consider it a success, too. I'd like to move the rest of static target-specific functions out of `SemaDeclAttr.cpp` like we're doing with built-ins in `SemaChecking.cpp` .
2024-05-30 19:59:59 +04:00
if (auto *A = Actions.AMDGPU().CreateAMDGPUFlatWorkGroupSizeAttr(
Reapply "[OpenMP] Add the `ompx_attribute` clause for target directives" This reverts commit 0d12683046ca75fb08e285f4622f2af5c82609dc and reapplies ef9ec4bbcca2fa4f64df47bc426f1d1c59ea47e2 with an extension to fix the Flang build. Differential Revision: https://reviews.llvm.org/D156184
2023-07-25 09:37:49 -07:00
PA, PA.getArgAsExpr(0), PA.getArgAsExpr(1)))
Attrs.push_back(A);
continue;
case ParsedAttr::AT_AMDGPUWavesPerEU:
if (!PA.checkAtLeastNumArgs(Actions, 1) ||
!PA.checkAtMostNumArgs(Actions, 2))
continue;
[clang] Introduce target-specific `Sema` components (#93179) This patch introduces `SemaAMDGPU`, `SemaARM`, `SemaBPF`, `SemaHexagon`, `SemaLoongArch`, `SemaMIPS`, `SemaNVPTX`, `SemaPPC`, `SemaSystemZ`, `SemaWasm`. This continues previous efforts to split Sema up. Additional context can be found in #84184 and #92682. I decided to bundle target-specific components together because of their low impact on `Sema`. That said, their impact on `SemaChecking.cpp` is far from low, and I consider it a success. Somewhat accidentally, I also moved Wasm- and AMDGPU-specific function from `SemaDeclAttr.cpp`, because they were exposed in `Sema`. That went well, and I consider it a success, too. I'd like to move the rest of static target-specific functions out of `SemaDeclAttr.cpp` like we're doing with built-ins in `SemaChecking.cpp` .
2024-05-30 19:59:59 +04:00
if (auto *A = Actions.AMDGPU().CreateAMDGPUWavesPerEUAttr(
Reapply "[OpenMP] Add the `ompx_attribute` clause for target directives" This reverts commit 0d12683046ca75fb08e285f4622f2af5c82609dc and reapplies ef9ec4bbcca2fa4f64df47bc426f1d1c59ea47e2 with an extension to fix the Flang build. Differential Revision: https://reviews.llvm.org/D156184
2023-07-25 09:37:49 -07:00
PA, PA.getArgAsExpr(0),
PA.getNumArgs() > 1 ? PA.getArgAsExpr(1) : nullptr))
Attrs.push_back(A);
continue;
case ParsedAttr::AT_CUDALaunchBounds:
if (!PA.checkAtLeastNumArgs(Actions, 1) ||
!PA.checkAtMostNumArgs(Actions, 2))
continue;
if (auto *A = Actions.CreateLaunchBoundsAttr(
PA, PA.getArgAsExpr(0),
Reland [NVPTX] Add support for maxclusterrank in launch_bounds (#66496) (#67667) This reverts commit 0afbcb20fd908f8bf9073697423da097be7db592.
2023-09-29 08:39:31 +02:00
PA.getNumArgs() > 1 ? PA.getArgAsExpr(1) : nullptr,
PA.getNumArgs() > 2 ? PA.getArgAsExpr(2) : nullptr))
Reapply "[OpenMP] Add the `ompx_attribute` clause for target directives" This reverts commit 0d12683046ca75fb08e285f4622f2af5c82609dc and reapplies ef9ec4bbcca2fa4f64df47bc426f1d1c59ea47e2 with an extension to fix the Flang build. Differential Revision: https://reviews.llvm.org/D156184
2023-07-25 09:37:49 -07:00
Attrs.push_back(A);
continue;
default:
Diag(Loc, diag::warn_omp_invalid_attribute_for_ompx_attributes) << PA;
continue;
};
}
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
return Actions.OpenMP().ActOnOpenMPXAttributeClause(
Attrs, Loc, T.getOpenLocation(), T.getCloseLocation());
Reapply "[OpenMP] Add the `ompx_attribute` clause for target directives" This reverts commit 0d12683046ca75fb08e285f4622f2af5c82609dc and reapplies ef9ec4bbcca2fa4f64df47bc426f1d1c59ea47e2 with an extension to fix the Flang build. Differential Revision: https://reviews.llvm.org/D156184
2023-07-25 09:37:49 -07: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 01:00:01 +00:00
/// Parsing of simple OpenMP clauses like 'default' or 'proc_bind'.
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00:00
///
/// default-clause:
[Clang][[OpenMP5.1] Initial parser/sema for default(private) clause This implements the default(private) clause as defined in OMP5.1 Differential Revision: https://reviews.llvm.org/D125912
2022-05-17 14:17:32 -07:00
/// 'default' '(' 'none' | 'shared' | 'private' | 'firstprivate' ')'
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00:00
///
[OPENMP] 'proc_bind' clause support - Parsing and sema analysis for OpenMP clause 'proc_bind' llvm-svn: 208060
2014-05-06 06:04:14 +00: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-03 13:22:35 -05:00
/// 'proc_bind' '(' 'master' | 'close' | 'spread' ')'
///
[OpenMP] Add parsing/sema/serialization for 'bind' clause. Differential Revision: https://reviews.llvm.org/D113154
2021-11-03 14:57:01 -07:00
/// bind-clause:
/// 'bind' '(' 'teams' | 'parallel' | 'thread' ')'
///
[OPENMP50]Support 'update' clause for 'depobj' directive. Added basic support (parsing/sema/serialization) for 'update' clause in 'depobj' directive.
2020-03-03 13:22:35 -05:00
/// update-clause:
Enable inoutset dependency-type in depend clause. Done in manner similar to mutexinoutset (see https://reviews.llvm.org/D57576) Runtime support already exists in LLVM OpenMP runtime (see https://reviews.llvm.org/D97085). The value used to identify an inoutset dependency type in the LLVM OpenMP runtime is 8. Some tests updated due to change in dependency type error messages that now include new dependency type. Also updated test/OpenMP/task_codegen.cpp to verify we emit the right code.
2022-02-08 08:33:52 -05:00
/// 'update' '(' 'in' | 'out' | 'inout' | 'mutexinoutset' |
/// 'inoutset' ')'
[OPENMP] 'proc_bind' clause support - Parsing and sema analysis for OpenMP clause 'proc_bind' llvm-svn: 208060
2014-05-06 06:04:14 +00: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-09 19:21:04 +00:00
OMPClause *Parser::ParseOpenMPSimpleClause(OpenMPClauseKind Kind,
bool ParseOnly) {
[clang] Use std::optional instead of llvm::Optional (NFC) This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to remove #include "llvm/ADT/Optional.h". This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2023-01-14 12:31:01 -08:00
std::optional<SimpleClauseData> Val = parseOpenMPSimpleClause(*this, Kind);
[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-23 16:11:14 +00:00
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-09 19:21:04 +00: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-12 22:19:40 -05:00
if (getLangOpts().OpenMP < 51 && Kind == OMPC_default &&
llvm::Optional::value => operator*/operator-> std::optional::value() has undesired exception checking semantics and is unavailable in older Xcode (see _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS). The call sites block std::optional migration. This makes `ninja clang` work in the absence of llvm::Optional::value.
2022-12-17 06:37:59 +00:00
(static_cast<DefaultKind>(Val->Type) == OMP_DEFAULT_private ||
static_cast<DefaultKind>(Val->Type) ==
Revert "Don't use Optional::hasValue (NFC)" This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.
2022-06-25 11:56:50 -07:00
OMP_DEFAULT_firstprivate)) {
llvm::Optional::value => operator*/operator-> std::optional::value() has undesired exception checking semantics and is unavailable in older Xcode (see _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS). The call sites block std::optional migration. This makes `ninja clang` work in the absence of llvm::Optional::value.
2022-12-17 06:37:59 +00:00
Diag(Val->LOpen, diag::err_omp_invalid_dsa)
<< getOpenMPClauseName(static_cast<DefaultKind>(Val->Type) ==
[Clang][[OpenMP5.1] Initial parser/sema for default(private) clause This implements the default(private) clause as defined in OMP5.1 Differential Revision: https://reviews.llvm.org/D125912
2022-05-17 14:17:32 -07:00
OMP_DEFAULT_private
? OMPC_private
: OMPC_firstprivate)
[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-12 22:19:40 -05:00
<< getOpenMPClauseName(OMPC_default) << "5.1";
return nullptr;
}
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
return Actions.OpenMP().ActOnOpenMPSimpleClause(
Kind, Val->Type, Val->TypeLoc, Val->LOpen, Val->Loc, Val->RLoc);
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00: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 01:00:01 +00:00
/// Parsing of OpenMP clauses like 'ordered'.
[OPENMP] Initial support for 'ordered' clause. llvm-svn: 211347
2014-06-20 09:44:06 +00:00
///
/// ordered-clause:
/// 'ordered'
///
[OPENMP] Initial support for 'nowait' clause. llvm-svn: 211352
2014-06-20 11:19:47 +00:00
/// nowait-clause:
/// 'nowait'
///
[OPENMP] Initial support for parsing and sema analysis of 'untied' clause. llvm-svn: 213257
2014-07-17 12:19:31 +00:00
/// untied-clause:
/// 'untied'
///
[OPENMP] Initial parsing and sema analysis of 'mergeable' clause. llvm-svn: 213262
2014-07-17 12:47:03 +00:00
/// mergeable-clause:
/// 'mergeable'
///
[OPENMP] Initial parsing and sema analysis for 'read' clause in 'atomic' directive. llvm-svn: 213717
2014-07-23 02:27:21 +00: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 10:37:12 +00: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 06:39:35 +00: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 10:51:44 +00: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-09 19:21:04 +00:00
OMPClause *Parser::ParseOpenMPClause(OpenMPClauseKind Kind, bool ParseOnly) {
[OPENMP] Initial support for 'ordered' clause. llvm-svn: 211347
2014-06-20 09:44:06 +00: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-09 19:21:04 +00:00
if (ParseOnly)
return nullptr;
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
return Actions.OpenMP().ActOnOpenMPClause(Kind, Loc, Tok.getLocation());
[OPENMP] Initial support for 'ordered' clause. llvm-svn: 211347
2014-06-20 09:44:06 +00: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 01:00:01 +00:00
/// Parsing of OpenMP clauses with single expressions and some additional
[OPENMP] Initial support for 'schedule' clause. llvm-svn: 211342
2014-06-20 07:16:17 +00: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 07:25:51 +00:00
/// 'schedule' '(' [ modifier [ ',' modifier ] ':' ] kind [',' expression ]
/// ')'
[OPENMP] Initial support for 'schedule' clause. llvm-svn: 211342
2014-06-20 07:16:17 +00: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 07:23:48 +00: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-26 16:37:23 +00: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-08 15:19:54 -04: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-26 16:37:23 +00: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-18 15:01:15 -04: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-09 19:21:04 +00:00
bool ParseOnly) {
[OPENMP] Initial support for 'schedule' clause. llvm-svn: 211342
2014-06-20 07:16:17 +00: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 07:23:48 +00:00
SourceLocation DelimLoc;
[OPENMP] Initial support for 'schedule' clause. llvm-svn: 211342
2014-06-20 07:16:17 +00: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-30 19:58:40 -05:00
getOpenMPClauseName(Kind).data()))
[OPENMP] Initial support for 'schedule' clause. llvm-svn: 211342
2014-06-20 07:16:17 +00: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 07:25:51 +00: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 07:23:48 +00: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 07:25:51 +00: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-23 19:53:05 +00: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-08-31 15:17:07 -04: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 07:25:51 +00: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-08-31 15:17:07 -04: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 07:25:51 +00: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 15:52:46 +00: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 07:25:51 +00: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-08-31 15:17:07 -04: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 07:25:51 +00: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 07:23:48 +00: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 07:25:51 +00: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 07:23:48 +00:00
Tok.is(tok::comma))
DelimLoc = ConsumeAnyToken();
Add OpenMP dist_schedule clause to distribute directive and related regression tests. llvm-svn: 257917
2016-01-15 18:50:31 +00: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-08-31 15:17:07 -04: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-15 18:50:31 +00: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-26 16:37:23 +00: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-15 13:02:06 -05: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-08-31 15:17:07 -04:00
Kind, Tok.isAnnotation() ? "" : PP.getSpelling(Tok), getLangOpts());
[OpenMP] Defaultmap: fixes scalar issue, adds all variable category (#99315) Fixes issue with defaultmap where scalar isn't handled correctly for present modifier. Adds all variable cateogry introduced in OpenMP 5.2 and alters existing tests for error messages to check OpenMP 5.2 defaultmap messages.
2024-07-25 21:30:14 +02:00
[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-15 13:02:06 -05: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-26 16:37:23 +00: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-08 15:19:54 -04: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-08-31 15:17:07 -04: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-08 15:19:54 -04: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());
}
[OpenMP] Basic parse and sema support for modifiers in order clause This patch gives basic parsing and semantic support for "modifiers" of order clause introduced in OpenMP 5.1 ( section 2.11.3 ) Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D127855
2022-12-12 15:51:38 -06:00
} else if (Kind == OMPC_order) {
enum { Modifier, OrderKind, NumberOfElements };
Arg.resize(NumberOfElements);
KLoc.resize(NumberOfElements);
Arg[Modifier] = OMPC_ORDER_MODIFIER_unknown;
Arg[OrderKind] = OMPC_ORDER_unknown;
unsigned KindModifier = getOpenMPSimpleClauseType(
Kind, Tok.isAnnotation() ? "" : PP.getSpelling(Tok), getLangOpts());
if (KindModifier > OMPC_ORDER_unknown) {
// Parse 'modifier'
Arg[Modifier] = KindModifier;
KLoc[Modifier] = 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) << "order modifier";
KindModifier = getOpenMPSimpleClauseType(
Kind, Tok.isAnnotation() ? "" : PP.getSpelling(Tok), getLangOpts());
}
Arg[OrderKind] = KindModifier;
KLoc[OrderKind] = Tok.getLocation();
if (Tok.isNot(tok::r_paren) && Tok.isNot(tok::comma) &&
Tok.isNot(tok::annot_pragma_openmp_end))
ConsumeAnyToken();
[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-18 15:01:15 -04: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-08-31 15:17:07 -04: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-18 15:01:15 -04:00
KLoc.push_back(Tok.getLocation());
ConsumeAnyToken();
// Parse ':'
ConsumeAnyToken();
} else {
Arg.push_back(OMPC_DEVICE_unknown);
KLoc.emplace_back();
}
[OpenMP] Initial parsing/sema for 'strict' modifier with 'grainsize' clause This patch gives basic parsing and semantic analysis support for 'strict' modifier with 'grainsize' clause of 'taskloop' construct introduced in OpenMP 5.1 (section 2.12.2) Differential Revision: https://reviews.llvm.org/D138217
2022-11-17 16:20:14 -08:00
} else if (Kind == OMPC_grainsize) {
// Parse optional <grainsize modifier> ':'
OpenMPGrainsizeClauseModifier Modifier =
static_cast<OpenMPGrainsizeClauseModifier>(getOpenMPSimpleClauseType(
Kind, Tok.isAnnotation() ? "" : PP.getSpelling(Tok),
getLangOpts()));
if (getLangOpts().OpenMP >= 51) {
if (NextToken().is(tok::colon)) {
Arg.push_back(Modifier);
KLoc.push_back(Tok.getLocation());
// Parse modifier
ConsumeAnyToken();
// Parse ':'
ConsumeAnyToken();
} else {
if (Modifier == OMPC_GRAINSIZE_strict) {
Diag(Tok, diag::err_modifier_expected_colon) << "strict";
// Parse modifier
ConsumeAnyToken();
}
Arg.push_back(OMPC_GRAINSIZE_unknown);
KLoc.emplace_back();
}
} else {
Arg.push_back(OMPC_GRAINSIZE_unknown);
KLoc.emplace_back();
}
[OpenMP] Initial parsing/sema for 'strict' modifier with 'num_tasks' clause This patch gives basic parsing and semantic analysis support for 'strict' modifier with 'num_tasks' clause of 'taskloop' construct introduced in OpenMP 5.1 (section 2.12.2) Differential Revision: https://reviews.llvm.org/D138328
2022-11-18 15:21:49 -08:00
} else if (Kind == OMPC_num_tasks) {
// Parse optional <num_tasks modifier> ':'
OpenMPNumTasksClauseModifier Modifier =
static_cast<OpenMPNumTasksClauseModifier>(getOpenMPSimpleClauseType(
Kind, Tok.isAnnotation() ? "" : PP.getSpelling(Tok),
getLangOpts()));
if (getLangOpts().OpenMP >= 51) {
if (NextToken().is(tok::colon)) {
Arg.push_back(Modifier);
KLoc.push_back(Tok.getLocation());
// Parse modifier
ConsumeAnyToken();
// Parse ':'
ConsumeAnyToken();
} else {
if (Modifier == OMPC_NUMTASKS_strict) {
Diag(Tok, diag::err_modifier_expected_colon) << "strict";
// Parse modifier
ConsumeAnyToken();
}
Arg.push_back(OMPC_NUMTASKS_unknown);
KLoc.emplace_back();
}
} else {
Arg.push_back(OMPC_NUMTASKS_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 07:23:48 +00: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 07:25:51 +00: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 12:10:05 +00: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-04 22:00:49 -06: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 07:23:48 +00: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 12:10:05 +00: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 07:23:48 +00: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 12:10:05 +00: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-04 22:00:49 -06: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 12:10:05 +00:00
}
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-23 19:53:05 +00: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 12:10:05 +00:00
TPA.Revert();
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-23 19:53:05 +00: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 07:23:48 +00:00
}
[OPENMP] Initial support for 'schedule' clause. llvm-svn: 211342
2014-06-20 07:16:17 +00:00
Add OpenMP dist_schedule clause to distribute directive and related regression tests. llvm-svn: 257917
2016-01-15 18:50:31 +00:00
bool NeedAnExpression = (Kind == OMPC_schedule && DelimLoc.isValid()) ||
(Kind == OMPC_dist_schedule && DelimLoc.isValid()) ||
[OpenMP] Initial parsing/sema for 'strict' modifier with 'grainsize' clause This patch gives basic parsing and semantic analysis support for 'strict' modifier with 'grainsize' clause of 'taskloop' construct introduced in OpenMP 5.1 (section 2.12.2) Differential Revision: https://reviews.llvm.org/D138217
2022-11-17 16:20:14 -08:00
Kind == OMPC_if || Kind == OMPC_device ||
[OpenMP] Initial parsing/sema for 'strict' modifier with 'num_tasks' clause This patch gives basic parsing and semantic analysis support for 'strict' modifier with 'num_tasks' clause of 'taskloop' construct introduced in OpenMP 5.1 (section 2.12.2) Differential Revision: https://reviews.llvm.org/D138328
2022-11-18 15:21:49 -08:00
Kind == OMPC_grainsize || Kind == OMPC_num_tasks;
[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 07:23:48 +00: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 15:07:51 +02:00
ExprResult LHS(ParseCastExpression(AnyCastExpr, false, NotTypeCast));
[OPENMP] Initial support for 'schedule' clause. llvm-svn: 211342
2014-06-20 07:16:17 +00: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-04 16:58:14 +00:00
Val =
Actions.ActOnFinishFullExpr(Val.get(), ELoc, /*DiscardedValue*/ false);
[OPENMP] Initial support for 'schedule' clause. llvm-svn: 211342
2014-06-20 07:16:17 +00: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-06 19:35:42 +00:00
SourceLocation RLoc = Tok.getLocation();
if (!T.consumeClose())
RLoc = T.getCloseLocation();
[OPENMP] Initial support for 'schedule' clause. llvm-svn: 211342
2014-06-20 07:16:17 +00: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 07:23:48 +00: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-09 19:21:04 +00:00
if (ParseOnly)
return nullptr;
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
return Actions.OpenMP().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-06 19:35:42 +00:00
Kind, Arg, Val.get(), Loc, T.getOpenLocation(), KLoc, DelimLoc, RLoc);
[OPENMP] Initial support for 'schedule' clause. llvm-svn: 211342
2014-06-20 07:16:17 +00:00
}
[OPENMP] Initial support of 'reduction' clause llvm-svn: 211007
2014-06-16 07:08:35 +00: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 07:08:49 +00:00
SourceLocation SymbolLocations[] = {OpLoc, OpLoc, SourceLocation()};
[OPENMP] Initial support of 'reduction' clause llvm-svn: 211007
2014-06-16 07:08:35 +00: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 09:12:29 +01: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 07:08:35 +00: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-18 22:18:41 +00: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 10:14:00 -04: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-18 22:18:41 +00: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 10:14:00 -04: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-08-31 15:17:07 -04: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-18 22:18:41 +00: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-22 22:29:42 +00:00
/// Parse the mapper modifier in map, to, and from clauses.
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
bool Parser::parseMapperModifier(SemaOpenMP::OpenMPVarListDataTy &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-22 22:29:42 +00:00
// 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,
[clang] Fix bugprone argument comments (NFC) Identified with bugprone-argument-comment.
2022-01-09 00:19:49 -08:00
/*ObjectHasErrors=*/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-22 22:29:42 +00: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();
}
Revert "Revert "[OpenMP][TR12] change property of map-type modifier."… (#91821) … (#90885)" This reverts commit eea81aa29848361eb5b24f24d2af643fdeb9adfd.
2024-05-13 07:39:23 -07:00
static OpenMPMapClauseKind isMapType(Parser &P);
[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-18 22:18:41 +00:00
/// Parse map-type-modifiers in map clause.
Revert "Revert "[OpenMP][TR12] change property of map-type modifier."… (#91821) … (#90885)" This reverts commit eea81aa29848361eb5b24f24d2af643fdeb9adfd.
2024-05-13 07:39:23 -07:00
/// 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 10:14:00 -04:00
/// where, map-type-modifier ::= always | close | mapper(mapper-identifier) |
/// present
Revert "Revert "[OpenMP][TR12] change property of map-type modifier."… (#91821) … (#90885)" This reverts commit eea81aa29848361eb5b24f24d2af643fdeb9adfd.
2024-05-13 07:39:23 -07:00
/// where, map-type ::= alloc | delete | from | release | to | tofrom
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
bool Parser::parseMapTypeModifiers(SemaOpenMP::OpenMPVarListDataTy &Data) {
Revert "Revert "[OpenMP][TR12] change property of map-type modifier."… (#91821) … (#90885)" This reverts commit eea81aa29848361eb5b24f24d2af643fdeb9adfd.
2024-05-13 07:39:23 -07:00
bool HasMapType = false;
SourceLocation PreMapLoc = Tok.getLocation();
StringRef PreMapName = "";
[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-19 16:38:20 +00:00
while (getCurToken().isNot(tok::colon)) {
OpenMPMapModifierKind TypeModifier = isMapModifier(*this);
Revert "Revert "[OpenMP][TR12] change property of map-type modifier."… (#91821) … (#90885)" This reverts commit eea81aa29848361eb5b24f24d2af643fdeb9adfd.
2024-05-13 07:39:23 -07:00
OpenMPMapClauseKind MapKind = isMapType(*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-18 22:18:41 +00: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 10:14:00 -04: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-08-31 15:17:07 -04: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-18 22:18:41 +00:00
Data.MapTypeModifiers.push_back(TypeModifier);
Data.MapTypeModifiersLoc.push_back(Tok.getLocation());
[OpenMP 5.2] Deprecate syntax of map modifiers without comma separators (#69534) The syntax of modifiers without comma separators in the map clause was deprecated in OpenMP 5.2. Reference: OpenMP 5.2 Spec, page 627, line 19
2023-10-24 10:17:52 -07:00
if (PP.LookAhead(0).isNot(tok::comma) &&
PP.LookAhead(0).isNot(tok::colon) && getLangOpts().OpenMP >= 52)
Diag(Tok.getLocation(), diag::err_omp_missing_comma)
<< "map type modifier";
[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-19 16:38:20 +00: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-22 22:29:42 +00: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-19 16:38:20 +00:00
return true;
[OpenMP 5.2] Deprecate syntax of map modifiers without comma separators (#69534) The syntax of modifiers without comma separators in the map clause was deprecated in OpenMP 5.2. Reference: OpenMP 5.2 Spec, page 627, line 19
2023-10-24 10:17:52 -07:00
if (Tok.isNot(tok::comma) && Tok.isNot(tok::colon) &&
getLangOpts().OpenMP >= 52)
Diag(Data.MapTypeModifiersLoc.back(), diag::err_omp_missing_comma)
<< "map type modifier";
Revert "Revert "[OpenMP][TR12] change property of map-type modifier."… (#91821) … (#90885)" This reverts commit eea81aa29848361eb5b24f24d2af643fdeb9adfd.
2024-05-13 07:39:23 -07:00
} else if (getLangOpts().OpenMP >= 60 && MapKind != OMPC_MAP_unknown) {
if (!HasMapType) {
HasMapType = true;
Data.ExtraModifier = MapKind;
MapKind = OMPC_MAP_unknown;
PreMapLoc = Tok.getLocation();
PreMapName = Tok.getIdentifierInfo()->getName();
} else {
Diag(Tok, diag::err_omp_more_one_map_type);
Diag(PreMapLoc, diag::note_previous_map_type_specified_here)
<< PreMapName;
}
ConsumeToken();
[clang] [OpenMP] New OpenMP 6.0 self_maps clause (#129888) Initial parsing/sema support for self maps in map and requirement clause [Sections 7.9.6 and 10.5.1.6 in OpenMP 6.0 spec]
2025-03-11 16:31:42 +05:30
} else if (TypeModifier == OMPC_MAP_MODIFIER_self) {
Data.MapTypeModifiers.push_back(TypeModifier);
Data.MapTypeModifiersLoc.push_back(Tok.getLocation());
if (PP.LookAhead(0).isNot(tok::comma) &&
PP.LookAhead(0).isNot(tok::colon))
Diag(Tok.getLocation(), diag::err_omp_missing_comma)
<< "map type modifier";
if (getLangOpts().OpenMP < 60)
Diag(Tok, diag::err_omp_unknown_map_type_modifier)
<< (getLangOpts().OpenMP >= 51
? (getLangOpts().OpenMP >= 52 ? 2 : 1)
: 0)
<< getLangOpts().OpenMPExtensions << 0;
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-18 22:18:41 +00: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-19 16:38:20 +00: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-18 22:18:41 +00:00
continue;
}
// Potential map-type token as it is followed by a colon.
Revert "Revert "[OpenMP][TR12] change property of map-type modifier."… (#91821) … (#90885)" This reverts commit eea81aa29848361eb5b24f24d2af643fdeb9adfd.
2024-05-13 07:39:23 -07:00
if (PP.LookAhead(0).is(tok::colon)) {
if (getLangOpts().OpenMP >= 60) {
break;
} else {
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 10:14:00 -04:00
Diag(Tok, diag::err_omp_unknown_map_type_modifier)
Add Parse/Sema for iterator for map clause.
2023-01-06 11:17:57 -06:00
<< (getLangOpts().OpenMP >= 51 ? (getLangOpts().OpenMP >= 52 ? 2 : 1)
: 0)
[clang] [OpenMP] New OpenMP 6.0 self_maps clause (#129888) Initial parsing/sema support for self maps in map and requirement clause [Sections 7.9.6 and 10.5.1.6 in OpenMP 6.0 spec]
2025-03-11 16:31:42 +05:30
<< getLangOpts().OpenMPExtensions
<< (getLangOpts().OpenMP >= 60 ? 1 : 0);
[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-19 16:38:20 +00: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-18 22:18:41 +00: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-19 16:38:20 +00: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-18 22:18:41 +00:00
}
Revert "Revert "[OpenMP][TR12] change property of map-type modifier."… (#91821) … (#90885)" This reverts commit eea81aa29848361eb5b24f24d2af643fdeb9adfd.
2024-05-13 07:39:23 -07:00
if (getLangOpts().OpenMP >= 60 && !HasMapType) {
if (!Tok.is(tok::colon)) {
Diag(Tok, diag::err_omp_unknown_map_type);
ConsumeToken();
} else {
Data.ExtraModifier = OMPC_MAP_unknown;
}
}
[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-19 16:38:20 +00: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-18 22:18:41 +00:00
}
/// Checks if the token is a valid map-type.
Fix sanitize problem. (#90800) Currently isMapType could return OpenMPMapModifierKind. The change is to return OpenMPMapTypeKind only, if it is not MapType Kind OMPC_MAP_unknown is returned.
2024-05-02 20:54:20 -07:00
/// If it is not MapType kind, OMPC_MAP_unknown is returned.
[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-18 22:18:41 +00: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();
Revert "Revert "[OpenMP][TR12] change property of map-type modifier."… (#91821) … (#90885)" This reverts commit eea81aa29848361eb5b24f24d2af643fdeb9adfd.
2024-05-13 07:39:23 -07:00
unsigned MapType =
getOpenMPSimpleClauseType(OMPC_map, PP.getSpelling(Tok), P.getLangOpts());
Fix sanitize problem. (#90800) Currently isMapType could return OpenMPMapModifierKind. The change is to return OpenMPMapTypeKind only, if it is not MapType Kind OMPC_MAP_unknown is returned.
2024-05-02 20:54:20 -07:00
if (MapType == OMPC_MAP_to || MapType == OMPC_MAP_from ||
MapType == OMPC_MAP_tofrom || MapType == OMPC_MAP_alloc ||
MapType == OMPC_MAP_delete || MapType == OMPC_MAP_release)
Revert "Revert "[OpenMP][TR12] change property of map-type modifier."… (#91821) … (#90885)" This reverts commit eea81aa29848361eb5b24f24d2af643fdeb9adfd.
2024-05-13 07:39:23 -07:00
return static_cast<OpenMPMapClauseKind>(MapType);
Fix sanitize problem. (#90800) Currently isMapType could return OpenMPMapModifierKind. The change is to return OpenMPMapTypeKind only, if it is not MapType Kind OMPC_MAP_unknown is returned.
2024-05-02 20:54:20 -07:00
return 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-18 22:18:41 +00:00
}
/// 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 11:01:50 +00:00
/// where, map-type ::= to | from | tofrom | alloc | release | delete
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
static void parseMapType(Parser &P, SemaOpenMP::OpenMPVarListDataTy &Data) {
[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-18 22:18:41 +00:00
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-20 11:04:57 -05: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-18 22:18:41 +00: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-01 15:06:38 -04: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();
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
SmallVector<SemaOpenMP::OMPIteratorData, 4> Data;
[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-01 15:06:38 -04:00
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();
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
SemaOpenMP::OMPIteratorData &D = Data.emplace_back();
[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-01 15:06:38 -04:00
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();
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
return Actions.OpenMP().ActOnOMPIteratorExpr(getCurScope(), IteratorKwLoc,
LLoc, RLoc, Data);
[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-01 15:06:38 -04:00
}
[OpenMP] Add parsing/sema support for omp_all_memory reserved locator Adds support for the reserved locator 'omp_all_memory' for use in depend clauses with 'out' or 'inout' dependence-types. Differential Revision: https://reviews.llvm.org/D125828
2022-05-17 10:11:00 -07:00
bool Parser::ParseOpenMPReservedLocator(OpenMPClauseKind Kind,
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
SemaOpenMP::OpenMPVarListDataTy &Data,
[OpenMP] Add parsing/sema support for omp_all_memory reserved locator Adds support for the reserved locator 'omp_all_memory' for use in depend clauses with 'out' or 'inout' dependence-types. Differential Revision: https://reviews.llvm.org/D125828
2022-05-17 10:11:00 -07:00
const LangOptions &LangOpts) {
// Currently the only reserved locator is 'omp_all_memory' which is only
// allowed on a depend clause.
if (Kind != OMPC_depend || LangOpts.OpenMP < 51)
return false;
if (Tok.is(tok::identifier) &&
Tok.getIdentifierInfo()->isStr("omp_all_memory")) {
if (Data.ExtraModifier == OMPC_DEPEND_outallmemory ||
Data.ExtraModifier == OMPC_DEPEND_inoutallmemory)
Diag(Tok, diag::warn_omp_more_one_omp_all_memory);
else if (Data.ExtraModifier != OMPC_DEPEND_out &&
Data.ExtraModifier != OMPC_DEPEND_inout)
Diag(Tok, diag::err_omp_requires_out_inout_depend_type);
else
Data.ExtraModifier = Data.ExtraModifier == OMPC_DEPEND_out
? OMPC_DEPEND_outallmemory
: OMPC_DEPEND_inoutallmemory;
ConsumeToken();
return true;
}
return false;
}
[OpenMP 5.2] Initial parsing and semantic analysis suppport for 'step' modifier on 'linear' clause Reference: (1) OpenMP 5.2 Specification - Seciton 5.4.6 Differential revision: https://reviews.llvm.org/D159546
2023-09-20 11:12:41 -07:00
/// Parse step size expression. Returns true if parsing is successfull,
/// otherwise returns false.
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
static bool parseStepSize(Parser &P, SemaOpenMP::OpenMPVarListDataTy &Data,
[OpenMP 5.2] Initial parsing and semantic analysis suppport for 'step' modifier on 'linear' clause Reference: (1) OpenMP 5.2 Specification - Seciton 5.4.6 Differential revision: https://reviews.llvm.org/D159546
2023-09-20 11:12:41 -07:00
OpenMPClauseKind CKind, SourceLocation ELoc) {
ExprResult Tail = P.ParseAssignmentExpression();
Sema &Actions = P.getActions();
Tail = Actions.ActOnFinishFullExpr(Tail.get(), ELoc,
/*DiscardedValue*/ false);
if (Tail.isUsable()) {
Data.DepModOrTailExpr = Tail.get();
Token CurTok = P.getCurToken();
if (CurTok.isNot(tok::r_paren) && CurTok.isNot(tok::comma)) {
P.Diag(CurTok, diag::err_expected_punc) << "step expression";
}
return true;
}
return false;
}
[clang][OpenMP][NFC] Move 'allocate' clause modifier parsing into fun… (#115775) …ction Parsing of 'allocate' clause modifier ('allocator') has been moved into a separate function in anticipation of adding another modifier ('align').
2024-11-11 16:11:16 -08:00
/// Parse 'allocate' clause modifiers.
[clang][OpenMP] Add 'align' modifier for 'allocate' clause (#121814) The 'align' modifier is now accepted in the 'allocate' clause. Added LIT tests covering codegen, PCH, template handling, and serialization for 'align' modifier. Added support for align-modifier to release notes. Testing - New allocate modifier LIT tests. - OpenMP LIT tests. - check-all
2025-01-13 05:44:48 -08:00
/// If allocator-modifier exists, return an expression for it. For both
/// allocator and align modifiers, set Data fields as appropriate.
[clang][OpenMP][NFC] Move 'allocate' clause modifier parsing into fun… (#115775) …ction Parsing of 'allocate' clause modifier ('allocator') has been moved into a separate function in anticipation of adding another modifier ('align').
2024-11-11 16:11:16 -08:00
static ExprResult
parseOpenMPAllocateClauseModifiers(Parser &P, OpenMPClauseKind Kind,
SemaOpenMP::OpenMPVarListDataTy &Data) {
const Token &Tok = P.getCurToken();
Preprocessor &PP = P.getPreprocessor();
ExprResult Tail;
[clang][OpenMP] Add 'align' modifier for 'allocate' clause (#121814) The 'align' modifier is now accepted in the 'allocate' clause. Added LIT tests covering codegen, PCH, template handling, and serialization for 'align' modifier. Added support for align-modifier to release notes. Testing - New allocate modifier LIT tests. - OpenMP LIT tests. - check-all
2025-01-13 05:44:48 -08:00
ExprResult Val;
SourceLocation RLoc;
bool AllocatorSeen = false;
bool AlignSeen = false;
SourceLocation CurrentModifierLoc = Tok.getLocation();
auto CurrentModifier = static_cast<OpenMPAllocateClauseModifier>(
[clang][OpenMP][NFC] Move 'allocate' clause modifier parsing into fun… (#115775) …ction Parsing of 'allocate' clause modifier ('allocator') has been moved into a separate function in anticipation of adding another modifier ('align').
2024-11-11 16:11:16 -08:00
getOpenMPSimpleClauseType(Kind, PP.getSpelling(Tok), P.getLangOpts()));
[clang][OpenMP] Add 'align' modifier for 'allocate' clause (#121814) The 'align' modifier is now accepted in the 'allocate' clause. Added LIT tests covering codegen, PCH, template handling, and serialization for 'align' modifier. Added support for align-modifier to release notes. Testing - New allocate modifier LIT tests. - OpenMP LIT tests. - check-all
2025-01-13 05:44:48 -08:00
// Modifiers did not exist before 5.1
if (P.getLangOpts().OpenMP < 51)
return P.ParseAssignmentExpression();
// An allocator-simple-modifier is exclusive and must appear alone. See
// OpenMP6.0 spec, pg. 313, L1 on Modifiers, as well as Table 5.1, pg. 50,
// description of "exclusive" property. If we don't recognized an explicit
// simple-/complex- modifier, assume we're looking at expression
// representing allocator and consider ourselves done.
if (CurrentModifier == OMPC_ALLOCATE_unknown)
return P.ParseAssignmentExpression();
do {
[clang][OpenMP][NFC] Move 'allocate' clause modifier parsing into fun… (#115775) …ction Parsing of 'allocate' clause modifier ('allocator') has been moved into a separate function in anticipation of adding another modifier ('align').
2024-11-11 16:11:16 -08:00
P.ConsumeToken();
if (Tok.is(tok::l_paren)) {
[clang][OpenMP] Add 'align' modifier for 'allocate' clause (#121814) The 'align' modifier is now accepted in the 'allocate' clause. Added LIT tests covering codegen, PCH, template handling, and serialization for 'align' modifier. Added support for align-modifier to release notes. Testing - New allocate modifier LIT tests. - OpenMP LIT tests. - check-all
2025-01-13 05:44:48 -08:00
switch (CurrentModifier) {
case OMPC_ALLOCATE_allocator: {
if (AllocatorSeen) {
P.Diag(Tok, diag::err_omp_duplicate_modifier)
<< getOpenMPSimpleClauseTypeName(OMPC_allocate, CurrentModifier)
<< getOpenMPClauseName(Kind);
} else {
Data.AllocClauseModifiers.push_back(CurrentModifier);
Data.AllocClauseModifiersLoc.push_back(CurrentModifierLoc);
}
BalancedDelimiterTracker AllocateT(P, tok::l_paren,
tok::annot_pragma_openmp_end);
AllocateT.consumeOpen();
Tail = P.ParseAssignmentExpression();
AllocateT.consumeClose();
AllocatorSeen = true;
break;
}
case OMPC_ALLOCATE_align: {
if (AlignSeen) {
P.Diag(Tok, diag::err_omp_duplicate_modifier)
<< getOpenMPSimpleClauseTypeName(OMPC_allocate, CurrentModifier)
<< getOpenMPClauseName(Kind);
} else {
Data.AllocClauseModifiers.push_back(CurrentModifier);
Data.AllocClauseModifiersLoc.push_back(CurrentModifierLoc);
}
Val = P.ParseOpenMPParensExpr(getOpenMPClauseName(Kind), RLoc);
if (Val.isUsable())
Data.AllocateAlignment = Val.get();
AlignSeen = true;
break;
}
default:
llvm_unreachable("Unexpected allocate modifier");
}
[clang][OpenMP][NFC] Move 'allocate' clause modifier parsing into fun… (#115775) …ction Parsing of 'allocate' clause modifier ('allocator') has been moved into a separate function in anticipation of adding another modifier ('align').
2024-11-11 16:11:16 -08:00
} else {
P.Diag(Tok, diag::err_expected) << tok::l_paren;
}
[clang][OpenMP] Add 'align' modifier for 'allocate' clause (#121814) The 'align' modifier is now accepted in the 'allocate' clause. Added LIT tests covering codegen, PCH, template handling, and serialization for 'align' modifier. Added support for align-modifier to release notes. Testing - New allocate modifier LIT tests. - OpenMP LIT tests. - check-all
2025-01-13 05:44:48 -08:00
if (Tok.isNot(tok::comma))
break;
P.ConsumeToken();
CurrentModifierLoc = Tok.getLocation();
CurrentModifier = static_cast<OpenMPAllocateClauseModifier>(
getOpenMPSimpleClauseType(Kind, PP.getSpelling(Tok), P.getLangOpts()));
// A modifier followed by a comma implies another modifier.
if (CurrentModifier == OMPC_ALLOCATE_unknown) {
P.Diag(Tok, diag::err_omp_expected_modifier) << getOpenMPClauseName(Kind);
break;
}
} while (!AllocatorSeen || !AlignSeen);
[clang][OpenMP][NFC] Move 'allocate' clause modifier parsing into fun… (#115775) …ction Parsing of 'allocate' clause modifier ('allocator') has been moved into a separate function in anticipation of adding another modifier ('align').
2024-11-11 16:11:16 -08:00
return Tail;
}
[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 05:28:34 +00:00
/// Parses clauses with list.
bool Parser::ParseOpenMPVarList(OpenMPDirectiveKind DKind,
OpenMPClauseKind Kind,
SmallVectorImpl<Expr *> &Vars,
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
SemaOpenMP::OpenMPVarListDataTy &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 05:28:34 +00:00
UnqualifiedId UnqualifiedReductionId;
[OPENMP] Initial support of 'reduction' clause llvm-svn: 211007
2014-06-16 07:08:35 +00: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-22 22:29:42 +00: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 14:25:19 +00:00
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00: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-18 19:10:49 +00: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 03:13:43 +00: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-30 19:58:40 -05: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 05:28:34 +00:00
return true;
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00: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-18 13:37:53 -04:00
bool HasIterator = false;
Add Parse/Sema for iterator for map clause.
2023-01-06 11:17:57 -06:00
bool InvalidIterator = 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 10:54:39 +00: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-29 18:44:28 -05:00
tok::annot_pragma_openmp_end);
[OPENMP] Initial support of 'reduction' clause llvm-svn: 211007
2014-06-16 07:08:35 +00: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-21 18:48:21 +00: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-23 17:30:38 -04: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-08-31 15:17:07 -04: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-23 17:30:38 -04:00
Data.ExtraModifierLoc = Tok.getLocation();
ConsumeToken();
assert(Tok.is(tok::comma) && "Expected comma.");
(void)ConsumeToken();
}
[OpenMP 6.0] Parse/Sema support for reduction over private variable with reduction clause. (#129938) Initial Parse/Sema support for reduction over private variable with reduction clause. Section 7.6.10 in in OpenMP 6.0 spec. - list item in a reduction clause can now be private in the enclosing context. - Added support for _original-sharing-modifier_ with reduction clause. --------- Co-authored-by: Chandra Ghale <ghale@pe31.hpc.amslabs.hpecorp.net>
2025-03-21 14:19:08 +05:30
// Handle original(private / shared) Modifier
if (Kind == OMPC_reduction && getLangOpts().OpenMP >= 60 &&
Tok.is(tok::identifier) && PP.getSpelling(Tok) == "original" &&
NextToken().is(tok::l_paren)) {
// Parse original(private) modifier.
ConsumeToken();
BalancedDelimiterTracker ParenT(*this, tok::l_paren, tok::r_paren);
ParenT.consumeOpen();
if (Tok.is(tok::kw_private)) {
Data.OriginalSharingModifier = OMPC_ORIGINAL_SHARING_private;
Data.OriginalSharingModifierLoc = Tok.getLocation();
ConsumeToken();
} else if (Tok.is(tok::identifier) &&
(PP.getSpelling(Tok) == "shared" ||
PP.getSpelling(Tok) == "default")) {
Data.OriginalSharingModifier = OMPC_ORIGINAL_SHARING_shared;
Data.OriginalSharingModifierLoc = Tok.getLocation();
ConsumeToken();
} else {
Diag(Tok.getLocation(), diag::err_expected)
<< "'private or shared or default'";
SkipUntil(tok::r_paren);
return false;
}
ParenT.consumeClose();
if (!Tok.is(tok::comma)) {
Diag(Tok.getLocation(), diag::err_expected) << "',' (comma)";
return false;
}
(void)ConsumeToken();
}
[OPENMP] Initial support of 'reduction' clause llvm-svn: 211007
2014-06-16 07:08:35 +00: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 10:19:46 +00: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-19 16:38:20 +00: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 10:19:46 +00:00
/*ObjectType=*/nullptr,
[clang] Fix bugprone argument comments (NFC) Identified with bugprone-argument-comment.
2022-01-09 00:19:49 -08:00
/*ObjectHasErrors=*/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 10:19:46 +00: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-19 16:38:20 +00:00
InvalidReductionId = ParseReductionId(
*this, Data.ReductionOrMapperIdScopeSpec, UnqualifiedReductionId);
[OPENMP] Initial support of 'reduction' clause llvm-svn: 211007
2014-06-16 07:08:35 +00: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 05:28:34 +00:00
if (Tok.is(tok::colon))
Data.ColonLoc = ConsumeToken();
else
[OPENMP] Initial support of 'reduction' clause llvm-svn: 211007
2014-06-16 07:08:35 +00: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 05:28:34 +00: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-19 16:38:20 +00: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 05:28:34 +00:00
Actions.GetNameFromUnqualifiedId(UnqualifiedReductionId);
[OMP5.2] Initial support for doacross clause.
2023-06-21 16:26:35 -07:00
} else if (Kind == OMPC_depend || Kind == OMPC_doacross) {
[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-01 15:06:38 -04: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-18 13:37:53 -04: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-01 15:06:38 -04: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-20 11:04:57 -05: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 14:25:19 +00:00
ColonProtectionRAIIObject ColonRAII(*this);
[OPENMP50]Basic support for conditional lastprivate. Added parsing/sema checks for conditional lastprivates.
2019-12-20 11:04:57 -05: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 10:14:00 -04: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-08-31 15:17:07 -04:00
getLangOpts());
[OPENMP50]Add 'default' modifier in reduction clauses. Added full support for 'default' modifier in the reduction clauses.
2020-03-23 17:30:38 -04:00
Data.ExtraModifierLoc = Tok.getLocation();
[OMP5.2] Initial support for doacross clause.
2023-06-21 16:26:35 -07:00
if ((Kind == OMPC_depend && Data.ExtraModifier == OMPC_DEPEND_unknown) ||
(Kind == OMPC_doacross &&
Data.ExtraModifier == OMPC_DOACROSS_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 14:25:19 +00: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 05:05:56 +00:00
// Special processing for depend(source) clause.
[OMP5.2] Initial support for doacross clause.
2023-06-21 16:26:35 -07:00
if (DKind == OMPD_ordered && Kind == OMPC_depend &&
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 05:05:56 +00: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 05:28:34 +00: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 05:05:56 +00: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 14:25:19 +00:00
}
[OPENMP] Formatting and code improvement, NFC. llvm-svn: 330634
2018-04-23 19:53:05 +00: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 05:28:34 +00:00
Data.ColonLoc = ConsumeToken();
[OPENMP52] Support Support omp_cur_iteration modifier for doacross clause. This is just syntax to make it easier for the user. It doesn't add any new functionality. for doacross(sink: omp_cur_iteration - 1) Equivalent to doacross(sink: ConterVar - 1, ...) doacross(source: omp_cur_iteration) Equivalent to doacross(source) And restriction is: OMP5.2 p.327 If vector is specified with the omp_cur_iteration keyword and with sink as the dependence-type then it must be omp_cur_iteration - 1. If vector is specified with source as the dependence-type then it must be omp_cur_iteration. Differential Revision: https://reviews.llvm.org/D154556
2023-07-05 08:04:07 -07:00
} else if (Kind != OMPC_doacross || Tok.isNot(tok::r_paren)) {
[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 05:05:56 +00:00
Diag(Tok, DKind == OMPD_ordered ? diag::warn_pragma_expected_colon_r_paren
: diag::warn_pragma_expected_colon)
[OMP5.2] Initial support for doacross clause.
2023-06-21 16:26:35 -07:00
<< (Kind == OMPC_depend ? "dependency type" : "dependence-type");
}
[OPENMP52] Support Support omp_cur_iteration modifier for doacross clause. This is just syntax to make it easier for the user. It doesn't add any new functionality. for doacross(sink: omp_cur_iteration - 1) Equivalent to doacross(sink: ConterVar - 1, ...) doacross(source: omp_cur_iteration) Equivalent to doacross(source) And restriction is: OMP5.2 p.327 If vector is specified with the omp_cur_iteration keyword and with sink as the dependence-type then it must be omp_cur_iteration - 1. If vector is specified with source as the dependence-type then it must be omp_cur_iteration. Differential Revision: https://reviews.llvm.org/D154556
2023-07-05 08:04:07 -07:00
if (Kind == OMPC_doacross) {
if (Tok.is(tok::identifier) &&
Tok.getIdentifierInfo()->isStr("omp_cur_iteration")) {
Data.ExtraModifier = Data.ExtraModifier == OMPC_DOACROSS_source
? OMPC_DOACROSS_source_omp_cur_iteration
: OMPC_DOACROSS_sink_omp_cur_iteration;
ConsumeToken();
}
if (Data.ExtraModifier == OMPC_DOACROSS_sink_omp_cur_iteration) {
if (Tok.isNot(tok::minus)) {
Diag(Tok, diag::err_omp_sink_and_source_iteration_not_allowd)
<< getOpenMPClauseName(Kind) << 0 << 0;
SkipUntil(tok::r_paren);
return false;
} else {
ConsumeToken();
SourceLocation Loc = Tok.getLocation();
uint64_t Value = 0;
if (Tok.isNot(tok::numeric_constant) ||
(PP.parseSimpleIntegerLiteral(Tok, Value) && Value != 1)) {
Diag(Loc, diag::err_omp_sink_and_source_iteration_not_allowd)
<< getOpenMPClauseName(Kind) << 0 << 0;
SkipUntil(tok::r_paren);
return false;
}
}
}
if (Data.ExtraModifier == OMPC_DOACROSS_source_omp_cur_iteration) {
if (Tok.isNot(tok::r_paren)) {
Diag(Tok, diag::err_omp_sink_and_source_iteration_not_allowd)
<< getOpenMPClauseName(Kind) << 1 << 1;
SkipUntil(tok::r_paren);
return false;
}
}
// Only the 'sink' case has the expression list.
if (Kind == OMPC_doacross &&
(Data.ExtraModifier == OMPC_DOACROSS_source ||
Data.ExtraModifier == OMPC_DOACROSS_source_omp_cur_iteration ||
Data.ExtraModifier == OMPC_DOACROSS_sink_omp_cur_iteration)) {
// Parse ')'.
T.consumeClose();
return 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 14:25:19 +00: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 10:54:39 +00: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-20 11:04:57 -05: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 10:54:39 +00: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-08-31 15:17:07 -04: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-23 17:30:38 -04: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 10:54:39 +00:00
LinearT.consumeOpen();
NeedRParenForLinear = true;
[OpenMP 5.2] Deprecate old syntax of linear clause (#70152) The syntax of the linear clause that specifies its argument and linear-modifier as linear-modifier(list) was deprecated since OpenMP 5.2 and the step modifier was added for specifying the linear step. Reference: OpenMP 5.2 Spec, Page 627, Line 15
2023-10-25 15:36:36 -07:00
if (getLangOpts().OpenMP >= 52)
Diag(Data.ExtraModifierLoc, diag::err_omp_deprecate_old_syntax)
<< "linear-modifier(list)" << getOpenMPClauseName(Kind)
<< "linear(list: [linear-modifier,] step(step-size))";
[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 10:54:39 +00:00
}
[OPENMP50]Basic support for conditional lastprivate. Added parsing/sema checks for conditional lastprivates.
2019-12-20 11:04:57 -05: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-08-31 15:17:07 -04: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-23 17:30:38 -04:00
Data.ExtraModifierLoc = Tok.getLocation();
ConsumeToken();
[OPENMP50]Basic support for conditional lastprivate. Added parsing/sema checks for conditional lastprivates.
2019-12-20 11:04:57 -05: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 05:32:03 +00:00
} else if (Kind == OMPC_map) {
Add Parse/Sema for iterator for map clause.
2023-01-06 11:17:57 -06:00
// Handle optional iterator map modifier.
if (Tok.is(tok::identifier) && PP.getSpelling(Tok) == "iterator") {
HasIterator = true;
EnterScope(Scope::OpenMPDirectiveScope | Scope::DeclScope);
Data.MapTypeModifiers.push_back(OMPC_MAP_MODIFIER_iterator);
Data.MapTypeModifiersLoc.push_back(Tok.getLocation());
ExprResult IteratorRes = ParseOpenMPIteratorsExpr();
Data.IteratorExpr = IteratorRes.get();
// Parse ','
ExpectAndConsume(tok::comma);
if (getLangOpts().OpenMP < 52) {
Diag(Tok, diag::err_omp_unknown_map_type_modifier)
<< (getLangOpts().OpenMP >= 51 ? 1 : 0)
[clang] [OpenMP] New OpenMP 6.0 self_maps clause (#129888) Initial parsing/sema support for self maps in map and requirement clause [Sections 7.9.6 and 10.5.1.6 in OpenMP 6.0 spec]
2025-03-11 16:31:42 +05:30
<< getLangOpts().OpenMPExtensions << 0;
Add Parse/Sema for iterator for map clause.
2023-01-06 11:17:57 -06:00
InvalidIterator = true;
}
}
[OpenMP] Parsing and sema support for map clause http://reviews.llvm.org/D14134 llvm-svn: 253849
2015-11-23 05:32:03 +00:00
// 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 00:01:58 +00: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-18 22:18:41 +00: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 00:01:58 +00:00
// spelling of the C++ delete keyword.
[OPENMP50]Basic support for conditional lastprivate. Added parsing/sema checks for conditional lastprivates.
2019-12-20 11:04:57 -05: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-23 17:30:38 -04:00
Data.ExtraModifierLoc = Tok.getLocation();
[OpenMP] Parsing and sema support for map clause http://reviews.llvm.org/D14134 llvm-svn: 253849
2015-11-23 05:32:03 +00: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-18 22:18:41 +00: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-29 18:44:28 -05: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-18 22:18:41 +00: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) {
Revert "Revert "[OpenMP][TR12] change property of map-type modifier."… (#91821) … (#90885)" This reverts commit eea81aa29848361eb5b24f24d2af643fdeb9adfd.
2024-05-13 07:39:23 -07:00
if (getLangOpts().OpenMP >= 60 && getCurToken().is(tok::colon))
Diag(Tok, diag::err_omp_map_modifier_specification_list);
[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-22 22:29:42 +00:00
IsInvalidMapperModifier = parseMapTypeModifiers(Data);
Revert "Revert "[OpenMP][TR12] change property of map-type modifier."… (#91821) … (#90885)" This reverts commit eea81aa29848361eb5b24f24d2af643fdeb9adfd.
2024-05-13 07:39:23 -07:00
if (getLangOpts().OpenMP < 60 && !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-19 16:38:20 +00: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-22 22:29:42 +00: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-18 22:18:41 +00:00
}
[OPENMP50]Basic support for conditional lastprivate. Added parsing/sema checks for conditional lastprivates.
2019-12-20 11:04:57 -05:00
if (Data.ExtraModifier == OMPC_MAP_unknown) {
Data.ExtraModifier = OMPC_MAP_tofrom;
[Clang][OpenMP] Add support for default to/from map types on target enter/exit data
2022-11-17 15:30:53 -06:00
if (getLangOpts().OpenMP >= 52) {
if (DKind == OMPD_target_enter_data)
Data.ExtraModifier = OMPC_MAP_to;
else if (DKind == OMPD_target_exit_data)
Data.ExtraModifier = OMPC_MAP_from;
}
[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 05:28:34 +00:00
Data.IsMapTypeImplicit = true;
[OpenMP] Parsing and sema support for map clause http://reviews.llvm.org/D14134 llvm-svn: 253849
2015-11-23 05:32:03 +00: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 05:28:34 +00: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-25 20:34:15 +00: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-29 12:18:45 -04: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-08-31 15:17:07 -04: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-29 12:18:45 -04: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-28 18:06:05 -04: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-28 20:26:56 -04: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-29 12:18:45 -04: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-28 18:06:24 -04: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-29 12:18:45 -04: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-22 22:29:42 +00: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-29 12:18:45 -04: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-18 13:37:53 -04:00
} else if (Kind == OMPC_allocate ||
(Kind == OMPC_affinity && Tok.is(tok::identifier) &&
PP.getSpelling(Tok) == "iterator")) {
[clang][OpenMP] Add 'align' modifier for 'allocate' clause (#121814) The 'align' modifier is now accepted in the 'allocate' clause. Added LIT tests covering codegen, PCH, template handling, and serialization for 'align' modifier. Added support for align-modifier to release notes. Testing - New allocate modifier LIT tests. - OpenMP LIT tests. - check-all
2025-01-13 05:44:48 -08:00
// Handle optional allocator and align modifiers followed by colon
// delimiter.
[OPENMP]Initial support for 'allocate' clause. Added parsing/sema analysis of the allocate clause. llvm-svn: 357068
2019-03-27 14:14:31 +00:00
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-18 13:37:53 -04: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) {
[clang][OpenMP][NFC] Move 'allocate' clause modifier parsing into fun… (#115775) …ction Parsing of 'allocate' clause modifier ('allocator') has been moved into a separate function in anticipation of adding another modifier ('align').
2024-11-11 16:11:16 -08:00
Tail = parseOpenMPAllocateClauseModifiers(*this, Kind, Data);
[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-18 13:37:53 -04:00
} 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 14:14:31 +00:00
Tail = Actions.ActOnFinishFullExpr(Tail.get(), T.getOpenLocation(),
/*DiscardedValue=*/false);
[clang][OpenMP] Add 'align' modifier for 'allocate' clause (#121814) The 'align' modifier is now accepted in the 'allocate' clause. Added LIT tests covering codegen, PCH, template handling, and serialization for 'align' modifier. Added support for align-modifier to release notes. Testing - New allocate modifier LIT tests. - OpenMP LIT tests. - check-all
2025-01-13 05:44:48 -08:00
if (Tail.isUsable() || Data.AllocateAlignment) {
[OPENMP]Initial support for 'allocate' clause. Added parsing/sema analysis of the allocate clause. llvm-svn: 357068
2019-03-27 14:14:31 +00:00
if (Tok.is(tok::colon)) {
[clang][OpenMP] Add 'align' modifier for 'allocate' clause (#121814) The 'align' modifier is now accepted in the 'allocate' clause. Added LIT tests covering codegen, PCH, template handling, and serialization for 'align' modifier. Added support for align-modifier to release notes. Testing - New allocate modifier LIT tests. - OpenMP LIT tests. - check-all
2025-01-13 05:44:48 -08:00
Data.DepModOrTailExpr = Tail.isUsable() ? Tail.get() : nullptr;
[OPENMP]Initial support for 'allocate' clause. Added parsing/sema analysis of the allocate clause. llvm-svn: 357068
2019-03-27 14:14:31 +00: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-18 13:37:53 -04: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 14:14:31 +00:00
TPA.Revert();
[clang][OpenMP] Add 'align' modifier for 'allocate' clause (#121814) The 'align' modifier is now accepted in the 'allocate' clause. Added LIT tests covering codegen, PCH, template handling, and serialization for 'align' modifier. Added support for align-modifier to release notes. Testing - New allocate modifier LIT tests. - OpenMP LIT tests. - check-all
2025-01-13 05:44:48 -08:00
if (Kind == OMPC_allocate && Data.AllocClauseModifiers.size()) {
[clang][OpenMP] Add 'allocator' modifier for 'allocate' clause. (#114883) The 'allocator' modifier is now accepted in the 'allocate' clause. Added LIT tests covering codegen, PCH, template handling, and serialization for 'allocator' modifier. Added support for allocator-modifier to release notes. Testing - New allocate modifier LIT tests. - OpenMP LIT tests. - check-all - relevant sollve_vv test cases tests/5.2/scope/test_scope_allocate_construct.c
2024-11-05 17:06:41 -08:00
SkipUntil(tok::r_paren, tok::annot_pragma_openmp_end,
StopBeforeMatch);
[clang][OpenMP] Add 'align' modifier for 'allocate' clause (#121814) The 'align' modifier is now accepted in the 'allocate' clause. Added LIT tests covering codegen, PCH, template handling, and serialization for 'align' modifier. Added support for align-modifier to release notes. Testing - New allocate modifier LIT tests. - OpenMP LIT tests. - check-all
2025-01-13 05:44:48 -08:00
Diag(Tok, diag::err_modifier_expected_colon) << "allocate clause";
[clang][OpenMP] Add 'allocator' modifier for 'allocate' clause. (#114883) The 'allocator' modifier is now accepted in the 'allocate' clause. Added LIT tests covering codegen, PCH, template handling, and serialization for 'allocator' modifier. Added support for allocator-modifier to release notes. Testing - New allocate modifier LIT tests. - OpenMP LIT tests. - check-all - relevant sollve_vv test cases tests/5.2/scope/test_scope_allocate_construct.c
2024-11-05 17:06:41 -08:00
}
[OPENMP]Initial support for 'allocate' clause. Added parsing/sema analysis of the allocate clause. llvm-svn: 357068
2019-03-27 14:14:31 +00:00
}
} 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-12 14:55:00 -07: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) {
[clang][OpenMP] Fix error handling of the adjust_args clause (#94696) Static verifier noticed the current code has logically dead code parsing the clause where IsComma is assigned. Fix this and improve the error message received when a bad adjust-op is specified. This will now be handled like 'map' where a nice diagnostic is given with the correct values, then parsing continues on the next clause reducing unhelpful diagnostics.
2024-06-24 13:37:49 -07:00
Diag(Tok, diag::err_omp_unknown_adjust_args_op);
SkipUntil(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-12 14:55:00 -07:00
} 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 07:08:35 +00:00
}
[OPENMP] Initial support for 'in_reduction' clause. Parsing/sema analysis for 'in_reduction' clause for task-based directives. llvm-svn: 308768
2017-07-21 18:48:21 +00:00
bool IsComma =
(Kind != OMPC_reduction && Kind != OMPC_task_reduction &&
[OMP5.2] Initial support for doacross clause.
2023-06-21 16:26:35 -07:00
Kind != OMPC_in_reduction && Kind != OMPC_depend &&
[clang][OpenMP] Fix error handling of the adjust_args clause (#94696) Static verifier noticed the current code has logically dead code parsing the clause where IsComma is assigned. Fix this and improve the error message received when a bad adjust-op is specified. This will now be handled like 'map' where a nice diagnostic is given with the correct values, then parsing continues on the next clause reducing unhelpful diagnostics.
2024-06-24 13:37:49 -07:00
Kind != OMPC_doacross && Kind != OMPC_map && Kind != OMPC_adjust_args) ||
[OPENMP] Initial support for 'in_reduction' clause. Parsing/sema analysis for 'in_reduction' clause for task-based directives. llvm-svn: 308768
2017-07-21 18:48:21 +00:00
(Kind == OMPC_reduction && !InvalidReductionId) ||
[OPENMP50]Basic support for conditional lastprivate. Added parsing/sema checks for conditional lastprivates.
2019-12-20 11:04:57 -05: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-12 14:55:00 -07:00
(Kind == OMPC_depend && Data.ExtraModifier != OMPC_DEPEND_unknown) ||
[OMP5.2] Initial support for doacross clause.
2023-06-21 16:26:35 -07:00
(Kind == OMPC_doacross && Data.ExtraModifier != OMPC_DOACROSS_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-12 14:55:00 -07:00
(Kind == OMPC_adjust_args &&
Data.ExtraModifier != OMPC_ADJUST_ARGS_unknown);
Parsing/Sema for OMPAlignedClause. llvm-svn: 209816
2014-05-29 14:36:25 +00: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 13:09:42 +00: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 03:13:43 +00: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-01 15:06:38 -04: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 13:09:42 +00:00
ColonProtectionRAIIObject ColonRAII(*this, MayHaveTail);
[OpenMP] Add parsing/sema support for omp_all_memory reserved locator Adds support for the reserved locator 'omp_all_memory' for use in depend clauses with 'out' or 'inout' dependence-types. Differential Revision: https://reviews.llvm.org/D125828
2022-05-17 10:11:00 -07:00
if (!ParseOpenMPReservedLocator(Kind, Data, getLangOpts())) {
// Parse variable
ExprResult VarExpr =
Actions.CorrectDelayedTyposInExpr(ParseAssignmentExpression());
if (VarExpr.isUsable()) {
Vars.push_back(VarExpr.get());
} 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 03:13:43 +00: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 08:43:42 +00:00
if (IsComma)
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00: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 08:43:42 +00: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 13:09:42 +00: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 11:26:11 +00: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 13:09:42 +00: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 10:54:39 +00:00
// Parse ')' for linear clause with modifier.
if (NeedRParenForLinear)
LinearT.consumeClose();
[OpenMP 5.2] Initial parsing and semantic analysis suppport for 'step' modifier on 'linear' clause Reference: (1) OpenMP 5.2 Specification - Seciton 5.4.6 Differential revision: https://reviews.llvm.org/D159546
2023-09-20 11:12:41 -07:00
// Parse ':' linear modifiers (val, uval, ref or step(step-size))
// or parse ':' alignment.
[OPENMP] parsing 'linear' clause (for directive 'omp simd') Differential Revision: http://reviews.llvm.org/D3272 llvm-svn: 206891
2014-04-22 13:09:42 +00:00
const bool MustHaveTail = MayHaveTail && Tok.is(tok::colon);
[OpenMP 5.2] Initial parsing and semantic analysis suppport for 'step' modifier on 'linear' clause Reference: (1) OpenMP 5.2 Specification - Seciton 5.4.6 Differential revision: https://reviews.llvm.org/D159546
2023-09-20 11:12:41 -07:00
bool StepFound = false;
bool ModifierFound = false;
[OPENMP] parsing 'linear' clause (for directive 'omp simd') Differential Revision: http://reviews.llvm.org/D3272 llvm-svn: 206891
2014-04-22 13:09:42 +00:00
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 05:28:34 +00: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 07:23:48 +00:00
SourceLocation ELoc = ConsumeToken();
[OpenMP 5.2] Initial parsing and semantic analysis suppport for 'step' modifier on 'linear' clause Reference: (1) OpenMP 5.2 Specification - Seciton 5.4.6 Differential revision: https://reviews.llvm.org/D159546
2023-09-20 11:12:41 -07:00
if (getLangOpts().OpenMP >= 52 && Kind == OMPC_linear) {
while (Tok.isNot(tok::r_paren)) {
if (Tok.is(tok::identifier)) {
// identifier could be a linear kind (val, uval, ref) or step
// modifier or step size
OpenMPLinearClauseKind LinKind =
static_cast<OpenMPLinearClauseKind>(getOpenMPSimpleClauseType(
Kind, Tok.isAnnotation() ? "" : PP.getSpelling(Tok),
getLangOpts()));
if (LinKind == OMPC_LINEAR_step) {
if (StepFound)
Diag(Tok, diag::err_omp_multiple_step_or_linear_modifier) << 0;
BalancedDelimiterTracker StepT(*this, tok::l_paren,
tok::annot_pragma_openmp_end);
SourceLocation StepModifierLoc = ConsumeToken();
// parse '('
if (StepT.consumeOpen())
Diag(StepModifierLoc, diag::err_expected_lparen_after) << "step";
// parse step size expression
StepFound = parseStepSize(*this, Data, Kind, Tok.getLocation());
if (StepFound)
Data.StepModifierLoc = StepModifierLoc;
// parse ')'
StepT.consumeClose();
} else if (LinKind >= 0 && LinKind < OMPC_LINEAR_step) {
if (ModifierFound)
Diag(Tok, diag::err_omp_multiple_step_or_linear_modifier) << 1;
Data.ExtraModifier = LinKind;
Data.ExtraModifierLoc = ConsumeToken();
ModifierFound = true;
} else {
StepFound = parseStepSize(*this, Data, Kind, Tok.getLocation());
}
} else {
// parse an integer expression as step size
StepFound = parseStepSize(*this, Data, Kind, Tok.getLocation());
}
if (Tok.is(tok::comma))
ConsumeToken();
if (Tok.is(tok::r_paren) || Tok.is(tok::annot_pragma_openmp_end))
break;
}
if (!StepFound && !ModifierFound)
Diag(ELoc, diag::err_expected_expression);
} else {
// for OMPC_aligned and OMPC_linear (with OpenMP <= 5.1)
ExprResult Tail = ParseAssignmentExpression();
Tail = Actions.ActOnFinishFullExpr(Tail.get(), ELoc,
/*DiscardedValue*/ false);
if (Tail.isUsable())
Data.DepModOrTailExpr = Tail.get();
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 03:13:43 +00: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-06 19:35:42 +00: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-01 15:06:38 -04: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-18 13:37:53 -04: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-01 15:06:38 -04:00
ExitScope();
[OMP5.2] Initial support for doacross clause.
2023-06-21 16:26:35 -07:00
return (Kind != OMPC_depend && Kind != OMPC_doacross && Kind != OMPC_map &&
Vars.empty()) ||
[OpenMP 5.2] Initial parsing and semantic analysis suppport for 'step' modifier on 'linear' clause Reference: (1) OpenMP 5.2 Specification - Seciton 5.4.6 Differential revision: https://reviews.llvm.org/D159546
2023-09-20 11:12:41 -07:00
(MustHaveTail && !Data.DepModOrTailExpr && StepFound) ||
InvalidReductionId || IsInvalidMapperModifier || InvalidIterator;
[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 05:28:34 +00: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 01:00:01 +00: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 09:41:22 -04: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 10:41:08 -04: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 05:28:34 +00: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-23 17:30:38 -04: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-18 20:17:46 +00: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-21 18:48:21 +00: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 05:28:34 +00: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-18 22:18:41 +00: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-22 22:29:42 +00: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 05:28:34 +00: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-26 17:39:58 +00: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-22 22:29:42 +00: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-26 17:49:04 +00: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-25 20:34:15 +00: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 15:37:16 +00: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 08:30:23 -04: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-13 17:16:49 +00:00
/// is_device_ptr-clause:
/// 'is_device_ptr' '(' list ')'
[clang][OpenMP5.1] Initial parsing/sema for has_device_addr Added basic parsing/sema/ support for the 'has_device_addr' clause. Differential Revision: https://reviews.llvm.org/D123402
2022-04-06 20:30:44 -07:00
/// has_device_addr-clause:
/// 'has_device_addr' '(' list ')'
[OPENMP]Initial support for 'allocate' clause. Added parsing/sema analysis of the allocate clause. llvm-svn: 357068
2019-03-27 14:14:31 +00:00
/// allocate-clause:
/// 'allocate' '(' [ allocator ':' ] list ')'
[clang][OpenMP] Add 'allocator' modifier for 'allocate' clause. (#114883) The 'allocator' modifier is now accepted in the 'allocate' clause. Added LIT tests covering codegen, PCH, template handling, and serialization for 'allocator' modifier. Added support for allocator-modifier to release notes. Testing - New allocate modifier LIT tests. - OpenMP LIT tests. - check-all - relevant sollve_vv test cases tests/5.2/scope/test_scope_allocate_construct.c
2024-11-05 17:06:41 -08:00
/// As of OpenMP 5.1 there's also
/// 'allocate' '(' allocate-modifier: list ')'
/// where allocate-modifier is: 'allocator' '(' allocator ')'
[OPENMP50]Initial support for inclusive clause. Added parsing/sema/serialization support for inclusive clause in scan directive.
2020-03-20 09:41:22 -04: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 10:41:08 -04: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 05:28:34 +00: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-09 19:21:04 +00: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 05:28:34 +00:00
SourceLocation Loc = Tok.getLocation();
SourceLocation LOpen = ConsumeToken();
SmallVector<Expr *, 4> Vars;
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
SemaOpenMP::OpenMPVarListDataTy 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 05:28:34 +00:00
if (ParseOpenMPVarList(DKind, Kind, Vars, Data))
[C++11] Use 'nullptr'. Parser edition. llvm-svn: 209275
2014-05-21 06:02:52 +00:00
return nullptr;
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00: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-09 19:21:04 +00: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-19 16:38:20 +00:00
OMPVarListLocTy Locs(Loc, LOpen, Data.RLoc);
[clang] Introduce `SemaOpenMP` (#88642) This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-16 16:36:53 +04:00
return Actions.OpenMP().ActOnOpenMPVarListClause(Kind, Vars, Locs, Data);
OpenMP: basic support for #pragma omp parallel llvm-svn: 186647
2013-07-19 03:13:43 +00:00
}
[Clang][OpenMP][Tile] Allow non-constant tile sizes. (#91345) Allow non-constants in the `sizes` clause such as ``` #pragma omp tile sizes(a) for (int i = 0; i < n; ++i) ``` This is permitted since tile was introduced in [OpenMP 5.1](https://www.openmp.org/spec-html/5.1/openmpsu53.html#x78-860002.11.9). It is possible to sneak-in negative numbers at runtime as in ``` int a = -1; #pragma omp tile sizes(a) ``` Even though it is not well-formed, it should still result in every loop iteration to be executed exactly once, an invariant of the tile construct that we should ensure. `ParseOpenMPExprListClause` is extracted-out to be reused by the `permutation` clause of the `interchange` construct. Some care was put into ensuring correct behavior in template contexts.
2024-05-13 16:10:58 +02:00
bool Parser::ParseOpenMPExprListClause(OpenMPClauseKind Kind,
SourceLocation &ClauseNameLoc,
SourceLocation &OpenLoc,
SourceLocation &CloseLoc,
SmallVectorImpl<Expr *> &Exprs,
bool ReqIntConst) {
assert(getOpenMPClauseName(Kind) == PP.getSpelling(Tok) &&
"Expected parsing to start at clause name");
ClauseNameLoc = ConsumeToken();
// Parse inside of '(' and ')'.
BalancedDelimiterTracker T(*this, tok::l_paren, tok::annot_pragma_openmp_end);
if (T.consumeOpen()) {
Diag(Tok, diag::err_expected) << tok::l_paren;
return true;
}
// Parse the list with interleaved commas.
do {
ExprResult Val =
ReqIntConst ? ParseConstantExpression() : ParseAssignmentExpression();
if (!Val.isUsable()) {
// Encountered something other than an expression; abort to ')'.
T.skipToEnd();
return true;
}
Exprs.push_back(Val.get());
} while (TryConsumeToken(tok::comma));
bool Result = T.consumeClose();
OpenLoc = T.getOpenLocation();
CloseLoc = T.getCloseLocation();
return Result;
}
Reference in New Issue Copy Permalink