aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Sema/SemaOpenMP.cpp
AgeCommit message (Collapse)AuthorFilesLines
2023-01-14[clang] Add #include <optional> (NFC)Kazu Hirata1-0/+1
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-11[OpenMP][FIX] Allow multiple `depend` clauses on a `taskwait nowait`Johannes Doerfert1-3/+4
Fixes https://github.com/llvm/llvm-project/issues/59941 Differential Revision: https://reviews.llvm.org/D141531
2023-01-11[OpenMP][5.1] Support `thread_limit` on `omp target`Johannes Doerfert1-1/+1
It is unclear to me what happens if we have two thread_limit clauses to choose from. I will recommend to the standards committee to disallow that. For now, we pick the teams one. Fixes https://github.com/llvm/llvm-project/issues/59940 Differential Revision: https://reviews.llvm.org/D141540
2022-12-20[OpenMP] Clang Support for taskwait nowait clauseSunil Kuravinakop1-0/+9
Support for taskwait nowait clause with placeholder for runtime changes. Reviewed By: cchen, ABataev Differential Revision: https://reviews.llvm.org/D131830
2022-12-19Fix host call to nohost function with host variant.Doru Bercea1-0/+18
2022-12-17llvm::Optional::value => operator*/operator->Fangrui Song1-33/+32
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-12[OpenMP] Basic parse and sema support for modifiers in order clauseChi Chun Chen1-15/+65
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-03[Sema] Use std::nullopt instead of None (NFC)Kazu Hirata1-32/+32
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-11-18[OPENMP5.1] Initial support for message clause.Jennifer Yu1-8/+31
2022-11-18[OpenMP] Initial parsing/sema for 'strict' modifier with 'num_tasks' clauseFazlay Rabbi1-10/+26
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[Clang][OpenMP] Add support for default to/from map types on target ↵Doru Bercea1-4/+7
enter/exit data
2022-11-17[OpenMP] Initial parsing/sema for 'strict' modifier with 'grainsize' clauseFazlay Rabbi1-14/+31
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[OPENMP5.1] Initial support for severity clauseJennifer Yu1-3/+39
Differential Revision:https://reviews.llvm.org/D138227
2022-11-17Fix declare target implementation to support enter.Doru Bercea1-3/+7
2022-11-15[OPENMP]Initial support for at clauseJennifer Yu1-2/+42
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-08Fix duplicate word typos; NFCRageking81-3/+3
This revision fixes typos where there are 2 consecutive words which are duplicated. There should be no code changes in this revision (only changes to comments and docs). Do let me know if there are any undesirable changes in this revision. Thanks.
2022-11-06[Sema] Use llvm::is_contained (NFC)Kazu Hirata1-2/+1
2022-11-02[OPENMP]Initial support for error directive.Jennifer Yu1-0/+20
Differential Revision: https://reviews.llvm.org/D137209
2022-10-07[Clang][OpenMP] Add one missing form of atomic compare captureShilei Tian1-14/+29
Two another atomic compare capture forms, `{ v = x; expr-stmt }` and `{ expr-stmt; v = x; }` where `expr-stmt` could be `cond-expr-stmt` are missing. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D135236
2022-10-05[Clang][OpenMP] Only check value if the expression is not instantiation ↵Shilei Tian1-15/+16
dependent Currently the following case fails: ``` template<typename Ty> Ty foo(Ty *addr, Ty val) { Ty v; #pragma omp atomic compare capture { v = *addr; if (*addr > val) *addr = val; } return v; } ``` The compiler complains `addr` is not a lvalue. That's because when an expression is instantiation dependent, we cannot tell if it is lvalue or not. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D135224
2022-09-20[Clang][OpenMP] Codegen generation for has_device_addr claues.Jennifer Yu1-7/+12
This patch add codegen support for the has_device_addr clause. It use the same logic of is_device_ptr. But passing &var instead pointer to var to kernal. Differential Revision: https://reviews.llvm.org/D134268
2022-09-15Revert "[OpenMP] Codegen aggregate for outlined function captures"Dhruva Chakrabarti1-53/+23
This reverts commit 7539e9cf811e590d9f12ae39673ca789e26386b4.
2022-09-15[OpenMP] Codegen aggregate for outlined function capturesGiorgis Georgakoudis1-23/+53
Parallel regions are outlined as functions with capture variables explicitly generated as distinct parameters in the function's argument list. That complicates the fork_call interface in the OpenMP runtime: (1) the fork_call is variadic since there is a variable number of arguments to forward to the outlined function, (2) wrapping/unwrapping arguments happens in the OpenMP runtime, which is sub-optimal, has been a source of ABI bugs, and has a hardcoded limit (16) in the number of arguments, (3) forwarded arguments must cast to pointer types, which complicates debugging. This patch avoids those issues by aggregating captured arguments in a struct to pass to the fork_call. Reviewed By: jdoerfert, jhuber6, ABataev Differential Revision: https://reviews.llvm.org/D102107
2022-09-03[clang] Qualify auto in range-based for loops (NFC)Kazu Hirata1-1/+1
2022-08-22[OpenMP][NFC] Use OMPInteropInfo in the OMPDeclareVariantAttr attributeMike Rice1-5/+3
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-18[OpenMP][NFC] Refactor code for interop parts of 'init' and 'append_args' ↵Mike Rice1-6/+4
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-14Use llvm::all_of (NFC)Kazu Hirata1-3/+2
2022-08-11[OpenMP] Allow data members in interop init/use/destroy clausesMike Rice1-28/+36
Previously a diagnostic was given if the expression was not strictly a DeclRef. Now also allow use of data members inside member functions. Differential Revision: https://reviews.llvm.org/D131222
2022-08-08[clang] LLVM_FALLTHROUGH => [[fallthrough]]. NFCFangrui Song1-4/+4
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-07Use llvm::is_contained (NFC)Kazu Hirata1-3/+2
2022-08-04[Clang][C++20] Support capturing structured bindings in lambdasCorentin Jabot1-2/+2
This completes the implementation of P1091R3 and P1381R1. This patch allow the capture of structured bindings both for C++20+ and C++17, with extension/compat warning. In addition, capturing an anonymous union member, a bitfield, or a structured binding thereof now has a better diagnostic. We only support structured bindings - as opposed to other kinds of structured statements/blocks. We still emit an error for those. In addition, support for structured bindings capture is entirely disabled in OpenMP mode as this needs more investigation - a specific diagnostic indicate the feature is not yet supported there. Note that the rest of P1091R3 (static/thread_local structured bindings) was already implemented. at the request of @shafik, i can confirm the correct behavior of lldb wit this change. Fixes https://github.com/llvm/llvm-project/issues/54300 Fixes https://github.com/llvm/llvm-project/issues/54300 Fixes https://github.com/llvm/llvm-project/issues/52720 Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D122768
2022-08-03Revert "[Clang][C++20] Support capturing structured bindings in lambdas"Corentin Jabot1-2/+2
This reverts commit 44f2baa3804a62ca793f0ff3e43aa71cea91a795. Breaks self builds and seems to have conformance issues.
2022-08-03[Clang][C++20] Support capturing structured bindings in lambdasCorentin Jabot1-2/+2
This completes the implementation of P1091R3 and P1381R1. This patch allow the capture of structured bindings both for C++20+ and C++17, with extension/compat warning. In addition, capturing an anonymous union member, a bitfield, or a structured binding thereof now has a better diagnostic. We only support structured bindings - as opposed to other kinds of structured statements/blocks. We still emit an error for those. In addition, support for structured bindings capture is entirely disabled in OpenMP mode as this needs more investigation - a specific diagnostic indicate the feature is not yet supported there. Note that the rest of P1091R3 (static/thread_local structured bindings) was already implemented. at the request of @shafik, i can confirm the correct behavior of lldb wit this change. Fixes https://github.com/llvm/llvm-project/issues/54300 Fixes https://github.com/llvm/llvm-project/issues/54300 Fixes https://github.com/llvm/llvm-project/issues/52720 Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D122768
2022-08-03Fix assert during the call to getCanonicalDecl.Jennifer Yu1-0/+3
https://github.com/llvm/llvm-project/issues/56884 The root problem is in isOpenMPRebuildMemberExpr, it is only need to rebuild for field expression. No need for member function call. The fix is to check field for member expression and skip rebuild for member function call. Differential Revision: https://reviews.llvm.org/D131024
2022-07-13[clang] Use value instead of getValue (NFC)Kazu Hirata1-33/+31
2022-07-12[clang, clang-tools-extra] Use has_value instead of hasValue (NFC)Kazu Hirata1-8/+8
2022-07-06[Clang][OpenMP] Enable floating-point operation for `atomic compare` seriesShilei Tian1-4/+3
D127041 introduced the support for `fmax` and `fmin` such that we can also reprent `atomic compare` and `atomic compare capture` with `atomicrmw` instruction. This patch simply lifts the limitation we set before. Depend on D127041. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D127042
2022-07-03[FPEnv] Allow CompoundStmt to keep FP optionsSerge Pavlov1-4/+5
This is a recommit of b822efc7404bf09ccfdc1ab7657475026966c3b2, reverted in dc34d8df4c48b3a8f474360970cae8a58e6c84f0. The commit caused fails because the test ast-print-fp-pragmas.c did not specify particular target, and it failed on targets which do not support constrained intrinsics. The original commit message is below. AST does not have special nodes for pragmas. Instead a pragma modifies some state variables of Sema, which in turn results in modified attributes of AST nodes. This technique applies to floating point operations as well. Every AST node that can depend on FP options keeps current set of them. This technique works well for options like exception behavior or fast math options. They represent instructions to the compiler how to modify code generation for the affected nodes. However treatment of FP control modes has problems with this technique. Modifying FP control mode (like rounding direction) usually requires operations on hardware, like writing to control registers. It must be done prior to the first operation that depends on the control mode. In particular, such operations are required for implementation of `pragma STDC FENV_ROUND`, compiler should set up necessary rounding direction at the beginning of compound statement where the pragma occurs. As there is no representation for pragmas in AST, the code generation becomes a complicated task in this case. To solve this issue FP options are kept inside CompoundStmt. Unlike to FP options in expressions, these does not affect any operation on FP values, but only inform the codegen about the FP options that act in the body of the statement. As all pragmas that modify FP environment may occurs only at the start of compound statement or at global level, such solution works for all relevant pragmas. The options are kept as a difference from the options in the enclosing compound statement or default options, it helps codegen to set only changed control modes. Differential Revision: https://reviews.llvm.org/D123952
2022-07-01Generate the capture for the field when the field is used in openmpJennifer Yu1-15/+179
region with implicit default inside the member function. This is to fix assert when field is referenced in OpenMP region with default (first|private) clause inside member function. The problem of assert is that the capture is not generated for the field. This patch is to generate capture when the field is used with implicit default, use it in the code, and save the capture off to make sure it is considered from that point and add first/private clauses. 1> Add new field ImplicitDefaultFirstprivateFDs in SharingMapTy, used to store generated capture fields info. 2> In function isOpenMPCaptureDecl: the caputer is generated and saved in ImplicitDefaultFirstprivateFDs. 3> Add new help functions: getImplicitFDCapExprDecl isImplicitDefaultFirstprivateFD addImplicitDefaultFirstprivateFD 4> Add addition argument in hasDSA to check default attribute for default(first|private). 5> The isImplicitDefaultFirstprivateFD is used in VisitDeclRefExpr to build the implicit clause. 6> Add new parameter "Context" for buildCaptureDecl, due to when capture field, the parent context is needed to be used. 7> Change in isOpenMPPrivateDecl where stop propagate the capture from the enclosing region for private variable. 8> In ActOnOpenMPFirstprivate/ActOnOpenMPPrivate, using captured info to generate first|private clause. 9> Add new function isOpenMPRebuildMemberExpr: use to determine if field needs to be rebuild during template instantiation. Differential Revision: https://reviews.llvm.org/D127803
2022-07-01[OpenMP] Initial parsing and semantic support for 'parallel masked taskloop ↵Fazlay Rabbi1-0/+97
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-07-01Revert "[FPEnv] Allow CompoundStmt to keep FP options"Serge Pavlov1-5/+4
On some buildbots test `ast-print-fp-pragmas.c` fails, need to investigate it. This reverts commit 0401fd12d4aa0553347fe34d666fb236d8719173. This reverts commit b822efc7404bf09ccfdc1ab7657475026966c3b2.
2022-07-01[FPEnv] Allow CompoundStmt to keep FP optionsSerge Pavlov1-4/+5
AST does not have special nodes for pragmas. Instead a pragma modifies some state variables of Sema, which in turn results in modified attributes of AST nodes. This technique applies to floating point operations as well. Every AST node that can depend on FP options keeps current set of them. This technique works well for options like exception behavior or fast math options. They represent instructions to the compiler how to modify code generation for the affected nodes. However treatment of FP control modes has problems with this technique. Modifying FP control mode (like rounding direction) usually requires operations on hardware, like writing to control registers. It must be done prior to the first operation that depends on the control mode. In particular, such operations are required for implementation of `pragma STDC FENV_ROUND`, compiler should set up necessary rounding direction at the beginning of compound statement where the pragma occurs. As there is no representation for pragmas in AST, the code generation becomes a complicated task in this case. To solve this issue FP options are kept inside CompoundStmt. Unlike to FP options in expressions, these does not affect any operation on FP values, but only inform the codegen about the FP options that act in the body of the statement. As all pragmas that modify FP environment may occurs only at the start of compound statement or at global level, such solution works for all relevant pragmas. The options are kept as a difference from the options in the enclosing compound statement or default options, it helps codegen to set only changed control modes. Differential Revision: https://reviews.llvm.org/D123952
2022-06-30[OpenMP] Initial parsing and sema support for 'parallel masked taskloop' ↵Fazlay Rabbi1-2/+80
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-28[OpenMP] Initial parsing and sema support for 'masked taskloop simd' constructFazlay Rabbi1-0/+67
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-27Adding support for target in_reductionRitanya B Bharadwaj1-1/+2
Implementing target in_reduction by wrapping target task with host task with in_reduction and if clause. This is in compliance with OpenMP 5.0 section: 2.19.5.6. So, this ``` for (int i=0; i<N; i++) { res = res+i } ``` will become ``` #pragma omp task in_reduction(+:res) if(0) #pragma omp target map(res) for (int i=0; i<N; i++) { res = res+i } ``` Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D125669
2022-06-25[clang] Don't use Optional::hasValue (NFC)Kazu Hirata1-9/+9
This patch replaces Optional::hasValue with the implicit cast to bool in conditionals only.
2022-06-25Revert "Don't use Optional::hasValue (NFC)"Kazu Hirata1-43/+46
This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.
2022-06-25Don't use Optional::hasValue (NFC)Kazu Hirata1-46/+43
2022-06-24[OpenMP] Initial parsing and sema support for 'masked taskloop' constructFazlay Rabbi1-0/+54
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-22[OpenMP] Add handling cases when filter(tid) appears with default(none)Fazlay Rabbi1-0/+1
Differential Revision: https://reviews.llvm.org/D128397
generated by cgit v1.1 at 2025-10-02 14:49:40 +0000