summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaOpenMP.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [OpenMP] Avoid remainder operations for loop index values on a collapsed ↵Gheorghe-Teodor Bercea2019-01-091-32/+44
| | | | | | | | | | | | | | | | loop nest. Summary: Change the strategy for computing loop index variables after collapsing a loop nest via the collapse clause by replacing the expensive remainder operation with multiplications and additions. Reviewers: ABataev, caomhin Reviewed By: ABataev Subscribers: guansong, arphaman, cfe-commits Differential Revision: https://reviews.llvm.org/D56413 llvm-svn: 350759
* [OpenMP] Add flag for preventing the extension to 64 bits for the collapse ↵Gheorghe-Teodor Bercea2019-01-091-11/+12
| | | | | | | | | | | | | | | | loop counter Summary: Introduce a compiler flag for cases when the user knows that the collapsed loop counter can be safely represented using at most 32 bits. This will prevent the emission of expensive mathematical operations (such as the div operation) on the iteration variable using 64 bits where 32 bit operations are sufficient. Reviewers: ABataev, caomhin Reviewed By: ABataev Subscribers: hfinkel, kkwli0, guansong, cfe-commits Differential Revision: https://reviews.llvm.org/D55928 llvm-svn: 350758
* Incorrect implicit data-sharing for nested tasksAlexey Bataev2019-01-091-8/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: There is a minor issue in how the implicit data-sharings for nested tasks are computed. For the following example: ``` int x; #pragma omp task shared(x) #pragma omp task x++; ``` We compute an implicit data-sharing of shared for `x` in the second task although I think that it should be firstprivate. Below you can find the part of the OpenMP spec that covers this example: - // In a task generating construct, if no default clause is present, a variable for which the data-sharing attribute is not determined by the rules above and that in the enclosing context is determined to be shared by all implicit tasks bound to the current team is shared.// - //In a task generating construct, if no default clause is present, a variable for which the data-sharing attribute is not determined by the rules above is firstprivate.// Since each implicit-task has its own copy of `x`, we shouldn't apply the first rule. Reviewers: ABataev Reviewed By: ABataev Subscribers: cfe-commits, rogfer01 Tags: #openmp Differential Revision: https://reviews.llvm.org/D56430 llvm-svn: 350734
* [OPENMP]Fix PR40191: Do not allow orphaned cancellation constructs.Alexey Bataev2019-01-081-4/+7
| | | | | | Prohibited use of the orphaned cancellation directives. llvm-svn: 350634
* [OpenMP] Refactor const restriction for linearJoel E. Denny2019-01-041-13/+5
| | | | | | | | | | | | | | As discussed in D56113, this patch refactors the implementation of the const restriction for linear to reuse a function introduced by D56113. A side effect is that, if a variable has mutable members, this diagnostic is now skipped, and the diagnostic for the variable not being an integer or pointer is reported instead. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D56299 llvm-svn: 350441
* [OpenMP] Refactor const restriction for reductionsJoel E. Denny2019-01-041-30/+30
| | | | | | | | | | | | | As discussed in D56113, this patch refactors the implementation of the const restriction for reductions to reuse a function introduced by D56113. A side effect is that diagnostics sometimes now say "variable" instead of "list item" when a list item is a variable. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D56298 llvm-svn: 350440
* [OpenMP] Replace predetermined shared for const variableJoel E. Denny2019-01-041-27/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following appears in OpenMP 3.1 sec. 2.9.1.1 as a predetermined data-sharing attribute: > Variables with const-qualified type having no mutable member are > shared. It does not appear in OpenmP 4.0, 4.5, or 5.0. This patch removes the implementation of that attribute when the requested OpenMP version is greater than 3.1. One effect of that removal is that `default(none)` affects const variables without mutable members. Also, without this patch, if a const variable without mutable members was explicitly lastprivate or private, it was an error because it was predetermined shared. Now, clang instead complains that it's const without mutable fields, which is a more intelligible diagnostic. That should be fine for all of the above versions because they all have something like the following, which is quoted from OpenMP 5.0 sec. 2.19.3: > A variable that is privatized must not have a const-qualified type > unless it is of class type with a mutable member. This restriction does > not apply to the firstprivate clause. reduction and linear clauses already have separate checks for const variables. Future patches will merge the implementations. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D56113 llvm-svn: 350439
* Refactor the way we handle diagnosing unused expression results.Aaron Ballman2019-01-041-22/+33
| | | | | | | | 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
* [OpenMP] Added support for explicit mapping of classes using 'this' pointer. ↵Patrick Lyster2019-01-021-1/+71
| | | | | | Differential revision: https://reviews.llvm.org/D55982 llvm-svn: 350252
* [OPENMP]Fix processing of the clauses on target combined directives.Alexey Bataev2018-12-281-4/+7
| | | | | | | | For constants with the predefined data-sharing clauses we may had troubles with the target combined directives. It may cause compiler crash in some corner cases. llvm-svn: 350127
* [AST] Store the callee and argument expressions of CallExpr in a trailing array.Bruno Ricci2018-12-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since CallExpr::setNumArgs has been removed, it is now possible to store the callee expression and the argument expressions of CallExpr in a trailing array. This saves one pointer per CallExpr, CXXOperatorCallExpr, CXXMemberCallExpr, CUDAKernelCallExpr and UserDefinedLiteral. Given that CallExpr is used as a base of the above classes we cannot use llvm::TrailingObjects. Instead we store the offset in bytes from the this pointer to the start of the trailing objects and manually do the casts + arithmetic. Some notes: 1.) I did not try to fit the number of arguments in the bit-fields of Stmt. This leaves some space for future additions and avoid the discussion about whether x bits are sufficient to hold the number of arguments. 2.) It would be perfectly possible to recompute the offset to the trailing objects before accessing the trailing objects. However the trailing objects are frequently accessed and benchmarks show that it is slightly faster to just load the offset from the bit-fields. Additionally, because of 1), we have plenty of space in the bit-fields of Stmt. Differential Revision: https://reviews.llvm.org/D55771 Reviewed By: rjmccall llvm-svn: 349910
* [OPENMP]Mark the loop as started when initialized.Alexey Bataev2018-12-191-0/+1
| | | | | | | | | Need to mark the loop as started when the initialization statement is found. It is required to prevent possible incorrect loop iteraton variable detection during template instantiation and fix the compiler crash during the codegen. llvm-svn: 349657
* [OpenMP] Fix data sharing analysis in nested clauseJoel E. Denny2018-12-191-7/+3
| | | | | | | | | | | | | | | | | | | | | | Without this patch, clang doesn't complain that X needs explicit data sharing attributes in the following: ``` #pragma omp target teams default(none) { #pragma omp parallel num_threads(X) ; } ``` However, clang does produce that complaint after the braces are removed. With this patch, clang complains in both cases. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D55861 llvm-svn: 349635
* [OPENMP] parsing and sema support for 'close' map-type-modifierKelvin Li2018-12-181-10/+33
| | | | | | | | | | | | 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
* Revert "Revert r347417 "Re-Reinstate 347294 with a fix for the failures.""Fangrui Song2018-11-301-18/+29
| | | | | | | | | It seems the two failing tests can be simply fixed after r348037 Fix 3 cases in Analysis/builtin-functions.cpp Delete the bad CodeGen/builtin-constant-p.c for now llvm-svn: 348053
* Revert r347417 "Re-Reinstate 347294 with a fix for the failures."Fangrui Song2018-11-301-29/+18
| | | | | | | | | | Kept the "indirect_builtin_constant_p" test case in test/SemaCXX/constant-expression-cxx1y.cpp while we are investigating why the following snippet fails: extern char extern_var; struct { int a; } a = {__builtin_constant_p(extern_var)}; llvm-svn: 348039
* Re-commit r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-281-18/+29
| | | | | | | This was reverted in r347656 due to me thinking it caused a miscompile of Chromium. Turns out it was the Chromium code that was broken. llvm-svn: 347756
* Revert r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-271-29/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This caused a miscompile in Chrome (see crbug.com/908372) that's illustrated by this small reduction: static bool f(int *a, int *b) { return !__builtin_constant_p(b - a) || (!(b - a)); } int arr[] = {1,2,3}; bool g() { return f(arr, arr + 3); } $ clang -O2 -S -emit-llvm a.cc -o - g() should return true, but after r347417 it became false for some reason. This also reverts the follow-up commits. r347417: > Re-Reinstate 347294 with a fix for the failures. > > Don't try to emit a scalar expression for a non-scalar argument to > __builtin_constant_p(). > > Third time's a charm! r347446: > The result of is.constant() is unsigned. r347480: > A __builtin_constant_p() returns 0 with a function type. r347512: > isEvaluatable() implies a constant context. > > Assume that we're in a constant context if we're asking if the expression can > be compiled into a constant initializer. This fixes the issue where a > __builtin_constant_p() in a compound literal was diagnosed as not being > constant, even though it's always possible to convert the builtin into a > constant. r347531: > A "constexpr" is evaluated in a constant context. Make sure this is reflected > if a __builtin_constant_p() is a part of a constexpr. llvm-svn: 347656
* Re-Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-211-18/+29
| | | | | | | | | Don't try to emit a scalar expression for a non-scalar argument to __builtin_constant_p(). Third time's a charm! llvm-svn: 347417
* [OPENMP]Fix handling of the LCVs in loop-based directives.Alexey Bataev2018-11-211-2/+8
| | | | | | | | | Loop-control variables with the default data-sharing attributes should not be captured in the OpenMP region as they are private by default. Also, default attributes should be emitted for such variables in the inner OpenMP regions for the correct data sharing during codegen. llvm-svn: 347409
* [OPENMP] Support relational-op != (not-equal) as one of the canonical Kelvin Li2018-11-211-18/+40
| | | | | | | | | | | | | | forms of random access iterator In OpenMP 4.5, only 4 relational operators are supported: <, <=, >, and >=. This work is to enable support for relational operator != (not-equal) as one of the canonical forms. Patch by Anh Tuyen Tran Differential Revision: https://reviews.llvm.org/D54441 llvm-svn: 347405
* Revert r347364 again, the fix was incomplete.Nico Weber2018-11-211-29/+18
| | | | llvm-svn: 347389
* Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-201-18/+29
| | | | | | | EvaluateAsInt() is sometimes called in a constant context. When that's the case, we need to specify it as so. llvm-svn: 347364
* [OPENMP]Fix PR39694: do not capture `this` in non-`this` region.Alexey Bataev2018-11-161-2/+9
| | | | | | | | | If lambda is used inside of the OpenMP region and captures `this`, we should recapture it in the OpenMP region also. But we should do this only if the OpenMP region is used in the context of the same class, just like the lambda. llvm-svn: 347096
* Add support for 'atomic_default_mem_order' clause on 'requires' directive. ↵Patrick Lyster2018-11-021-0/+25
| | | | | | Also renamed test files relating to 'requires'. Differntial review: https://reviews.llvm.org/D53513 llvm-svn: 345967
* Create ConstantExpr classBill Wendling2018-10-311-2/+2
| | | | | | | | | | | | | | | | A ConstantExpr class represents a full expression that's in a context where a constant expression is required. This class reflects the path the evaluator took to reach the expression rather than the syntactic context in which the expression occurs. In the future, the class will be expanded to cache the result of the evaluated expression so that it's not needlessly re-evaluated Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D53475 llvm-svn: 345692
* [OPENMP] Support for mapping of the lambdas in target regions.Alexey Bataev2018-10-301-4/+54
| | | | | | | | | | Added support for mapping of lambdas in the target regions. It scans all the captures by reference in the lambda, implicitly maps those variables in the target region and then later reinstate the addresses of references in lambda to the correct addresses of the captured|privatized variables. llvm-svn: 345609
* [OPENMP]Fix PR39372: Does not complain about loop bound variable notAlexey Bataev2018-10-291-0/+2
| | | | | | | | | | | being shared. According to the standard, the variables with unspecified data-sharing attributes in presence of `default(none)` clause must be reported to users. Compiler did not generate error reports for the variables used in other OpenMP regions. Patch fixes this. llvm-svn: 345533
* [OpenMP] Fix condition.Gheorghe-Teodor Bercea2018-10-291-1/+2
| | | | | | | | | | | | | | Summary: Iteration variable must be strictly less than the number of iterations. This fixes a bug introduced by previous patch D53448. Reviewers: ABataev, caomhin Reviewed By: ABataev Subscribers: guansong, cfe-commits Differential Revision: https://reviews.llvm.org/D53827 llvm-svn: 345527
* [OpenMP][NVPTX] Use single loops when generating code for distribute ↵Gheorghe-Teodor Bercea2018-10-291-2/+15
| | | | | | | | | | | | | | | | parallel for Summary: This patch adds a new code generation path for bound sharing directives containing distribute parallel for. The new code generation scheme applies to chunked schedules on distribute and parallel for directives. The scheme simplifies the code that is being generated by eliminating the need for an outer for loop over chunks for both distribute and parallel for directives. In the case of distribute it applies to any sized chunk while in the parallel for case it only applies when chunk size is 1. Reviewers: ABataev, caomhin Reviewed By: ABataev Subscribers: jholewinski, guansong, cfe-commits Differential Revision: https://reviews.llvm.org/D53448 llvm-svn: 345509
* [OPENMP] Do not capture private loop counters.Alexey Bataev2018-10-291-20/+86
| | | | | | | | If the loop counter is not declared in the context of the loop and it is private, such loop counters should not be captured in the outlined regions. llvm-svn: 345505
* [OPENMP]Fix PR39422: variables are not firstprivatized in task context.Alexey Bataev2018-10-251-2/+25
| | | | | | | | | | | According to the OpenMP standard, In a task generating construct, if no default clause is present, a variable for which the data-sharing attribute is not determined by the rules above is firstprivatized. Compiler tries to implement this, but if the variable is not directly used in the task context, this variable may not be firstprivatized. Patch fixes this problem. llvm-svn: 345277
* [OPENMP]Fix PR39366: do not try to private field if it is not captured.Alexey Bataev2018-10-241-2/+8
| | | | | | | | | The compiler is crashing if we trying to post-capture the fields implicitly captured inside of the task constructs. Seems, this kind of processing is not supported and such fields should not be firstprivatized. llvm-svn: 345177
* Add support for 'dynamic_allocators' clause on 'requires' directive. ↵Patrick Lyster2018-10-111-0/+13
| | | | | | Differential Revision: https://reviews.llvm.org/D53079 llvm-svn: 344249
* [OPENMP] Add reverse_offload clause to requires directivePatrick Lyster2018-10-031-0/+13
| | | | llvm-svn: 343711
* Add support for unified_shared_memory clause on requires directivePatrick Lyster2018-10-011-0/+13
| | | | llvm-svn: 343472
* [OPENMP]Fix PR39084: Check datasharing attributes of reduction variables only.Alexey Bataev2018-09-281-60/+58
| | | | | | | | According to OpenMP, the reduction item must be shared in parent region. But the item can be an array section or array subscript. In this case, we should not check for the datasharing of the base declaration. llvm-svn: 343356
* [OPENMP] Add support for OMP5 requires directive + unified_address clauseKelvin Li2018-09-261-1/+77
| | | | | | | | | 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
* [OPENMP] Add support for mapping memory pointed by member pointer.Alexey Bataev2018-09-201-0/+20
| | | | | | Added support for map(s, s.ptr[0:1]) kind of mapping. llvm-svn: 342648
* [OPENMP] Fix PR38903: Crash on instantiation of the non-dependentAlexey Bataev2018-09-131-0/+10
| | | | | | | | | | | declare reduction. If the declare reduction construct with the non-dependent type is defined in the template construct, the compiler might crash on the template instantition. Reworked the whole instantiation scheme for the declare reduction constructs to fix this problem correctly. llvm-svn: 342151
* [OPENMP] Fix PR38902: support ADL for declare reduction constructs.Alexey Bataev2018-09-121-1/+106
| | | | | | | Added support for argument-dependent lookup when trying to find the required declare reduction decl. llvm-svn: 342062
* [OPENMP] Simplified checks for declarations in declare target regions.Alexey Bataev2018-09-111-106/+36
| | | | | | | | Sema analysis should not mark functions as an implicit declare target, it may break codegen. Simplified semantic analysis and removed extra code for implicit declare target functions. llvm-svn: 341939
* [OpenMP] Add support for nested 'declare target' directivesKelvin Li2018-09-101-8/+3
| | | | | | | | | | | Add the capability to nest multiple declare target directives - including header files within a declare target region. Differential Revision: https://reviews.llvm.org/D51378 Patch by Patrick Lyster llvm-svn: 341766
* [OPENMP] Fix processing of declare target construct.Alexey Bataev2018-08-141-24/+5
| | | | | | | The attribute marked as inheritable since OpenMP 5.0 supports it + additional fixes to support new functionality. llvm-svn: 339704
* [OPENMP] Fix emission of the loop doacross constructs.Alexey Bataev2018-08-131-84/+185
| | | | | | | The number of loops associated with the OpenMP loop constructs should not be considered as the number loops to collapse. llvm-svn: 339603
* Revert "[OPENMP] Fix emission of the loop doacross constructs."Alexey Bataev2018-08-131-179/+84
| | | | | | This reverts commit r339568 because of the problems with the buildbots. llvm-svn: 339574
* [OPENMP] Fix emission of the loop doacross constructs.Alexey Bataev2018-08-131-84/+179
| | | | | | | The number of loops associated with the OpenMP loop constructs should not be considered as the number loops to collapse. llvm-svn: 339568
* Port getLocEnd -> getEndLocStephen Kelly2018-08-091-4/+4
| | | | | | | | | | Reviewers: teemperor! Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50351 llvm-svn: 339386
* Port getLocStart -> getBeginLocStephen Kelly2018-08-091-75/+75
| | | | | | | | | | Reviewers: teemperor! Subscribers: jholewinski, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D50350 llvm-svn: 339385
* [OPENMP] Mark variables captured in declare target region as implicitlyAlexey Bataev2018-08-071-7/+16
| | | | | | | | | declare target. According to OpenMP 5.0, variables captured in lambdas in declare target regions must be considered as implicitly declare target. llvm-svn: 339152
OpenPOWER on IntegriCloud