Re-land commit 3787fd942f
This patch adds support for storing OpenMP REQUIRES information in the
semantics symbols for programs/subprograms and modules/submodules, and
populates them during directive resolution. A pass is added to name resolution
that makes sure this information is also propagated across top-level programs,
functions and subprograms.
Storing REQUIRES information inside of semantics symbols will also allow
supporting the propagation of this information across Fortran modules. This
will come as a separate patch.
The `bool DirectiveAttributeVisitor::Pre(const parser::SpecificationPart &x)`
method is removed since it resulted in specification parts being visited twice.
This is patch 3/5 of a series splitting D149337 to simplify review.
Differential Revision: https://reviews.llvm.org/D157983
Changes in this commit make some gfortran tests crash the compiler. It is
likely trying to dereference undefined symbol pointers.
This reverts commit 3787fd942f.
This patch adds support for storing OpenMP REQUIRES information in the
semantics symbols for programs/subprograms and modules/submodules, and
populates them during directive resolution. A pass is added to name resolution
that makes sure this information is also propagated across top-level programs,
functions and subprograms.
Storing REQUIRES information inside of semantics symbols will also allow
supporting the propagation of this information across Fortran modules. This
will come as a separate patch.
The `bool DirectiveAttributeVisitor::Pre(const parser::SpecificationPart &x)`
method is removed since it resulted in specification parts being visited twice.
This is patch 3/5 of a series splitting D149337 to simplify review.
Differential Revision: https://reviews.llvm.org/D157983
Executable allocate directives require that list items show up in the corresponding allocate statement. This patch is dependent on revision D150428 and applies the semantic check introduced there to allocate directives associated with allocate statements.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D150483
Added support for following semantic check for MAP clause.
- A list item cannot appear in both a map clause and a data-sharing attribute clause on the same target construct.
Reviewed By: NimishMishra
Differential Revision: https://reviews.llvm.org/D158807
Unlike other executable constructs with associating selectors, the
selector of a SELECT RANK construct can have the ALLOCATABLE or POINTER
attribute, and will work as an allocatable or object pointer within
each rank case, so long as there is no RANK(*) case.
Getting this right exposed a correctness risk with the popular
predicate IsAllocatableOrPointer() -- it will be true for procedure
pointers as well as object pointers, and in many contexts, a procedure
pointer should not be acceptable. So this patch adds the new predicate
IsAllocatableOrObjectPointer(), and updates some call sites of the original
function to use the new one.
Differential Revision: https://reviews.llvm.org/D159043
Some compilers accept `!$acc end loop` associated with an `!$acc loop`
directive. This patch updates the acc loop parser to accept it as well.
The parser is also updated to be stricter on the following statement
to match the OpenACC combined construct parser.
The rewrite canonicalization is not a rewrite anymore and the naming
will be updated in a follow up patch for the Loop and Combined constructs.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D159015
When acc routine is in a function, the first symbol resolved
was the function result and not the function name itself. It was
then failing the deferred attachment because the mangled name
had the entity attach to it. This patch fix the name resolution
for the function name in acc routine directive.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D158868
This patch propagates the acc routine information
to the module file so they can be used by the caller.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D158541
Added semantic support for following restriction which applies to OMP DISTRIBUTE directives
- A list item may appear in a firstprivate or lastprivate clause but not both.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D157465
Distinguish between copyin and copyin with the readonly modifier.
Depends on D157121
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D157125
This patch moves directive sets defined internally in Semantics to a header
accessible by other stages of the compiler to enable reuse. Some sets are
renamed/rearranged and others are lifted from local definitions to provide
a single source of truth.
Differential Revision: https://reviews.llvm.org/D157090
Flags were not correctly set for symbols appearing in the OpenACC declare
directive in module declaration part.
Also some missing flags for OpenACC are added. This makes the Flags enum
> 64 and then the implementation switch to std::bitset as defined in
`flang/include/flang/Common/enum-set.h`. Therefore, `constexpr` cannot be
used for set of flags in `flang/lib/Semantics/resolve-directives.cpp`.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D157042
The following restrictions for USE_DEVICE_PTR and USE_DEVICE_ADDR clauses on OMP TARGET DATA directive are implemented in this patch.
- A list item may not be specified more than once in use_device_ptr clauses that appear on the directive.
- A list item may not be specified more than once in use_device_addr clauses that appear on the directive.
- A list item may not be specified in both a use_device_addr clause and a use_device_ptr clause on the directive.
- A list item that appears in a use_device_ptr or use_device_addr clause must not be a structure element.
- A list item that appears in a use_device_ptr must be of type C_PTR.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D155133
This patch applies the semantic checks for executable allocation directives to the new allocators construct. It also introduces a new check that ensures all items in the list appear in the corresponding Fortran allocate statement.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D150428
This patch adds the skeleton and the basic lowering for OpenACC declare
construct when located in the module declaration. This patch just lower the
create clause with or without modifier. Other clause and global descrutor
lowering will come in follow up patches to keep this one small enough for
review.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D156266
The following error was triggered in the added test case.
This is a false positive.
COMMON block must be declared in the same scoping unit in which the OpenACC directive or clause appears
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D154742
Wrong error was reported mentioning that the common block was in
more than one data sharing clause.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D154393
This is an assisting patch which is implemented to address review comment to switch std::list<Name> to OmpObjectlist from https://reviews.llvm.org/D142722.
Also addressed a semantic check https://github.com/llvm/llvm-project/issues/61161 OpenMP 5.2 standard states that only pointer variables (C_PTR, Cray pointers, POINTER or ALLOCATABLE items) can appear in SIMD aligned clause (section 5.11). And not to allow common block names on an ALIGNED clause.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D152637
Name resolution was failing when the routine name is
a function/subroutine in the parent scope.
Reviewed By: vzakhari
Differential Revision: https://reviews.llvm.org/D154002
Some symbols were not resolved in the device, host and self clause
resulting in an `Internal: no symbol found` error.
This patch adds symbol resolution for these clauses.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D153919
This patch adds parser support for the force modifier on the collapse clause
introduced in OpenACC 3.3.
Lowering will currently hit a TODO as the MLIR representation of the acc.loop
might need some update.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D151974
Currently symbols are not resolved for declare target
after they've been modified by prior passes. This can
lead to missing or incorrect symbols in subsequent
compiler phases when declare target is used with
more complex types e.g. common block.
This patch should allow these symbols to be
resolved appropriately.
Reviewers: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D151993
This is a valid usage. We do not handle it as of now. Gfortran/Ifx produces an error, possibly because `do concurrent` was not allowed in previous versions of the OpenMP standard.
Fixes#62649
Reviewed By: Leporacanthicus
Differential Revision: https://reviews.llvm.org/D150869
Addresses the same issue as the following abandoned revision: D104391.
Rewrite leading declarative allocations so they are nested within their respective executable allocate directive
Original:
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPExecutableAllocate
After rewriting:
ExecutionPartConstruct -> OpenMPExecutableAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D148409
Co-authored-by: Isaac Perry <isaac.perry@arm.com>
Addresses the same issue as the following abandoned revision: D104391.
Rewrite leading declarative allocations so they are nested within their respective executable allocate directive
Original:
```
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPExecutableAllocate
```
After rewriting:
```
ExecutionPartConstruct -> OpenMPExecutableAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
```
Co-authored-by: Isaac Perry <isaac.perry@arm.com>
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D148409
This reverts commit 5faf45a3d2.
Once again arcanist stripped the co-author metadata. I'm going to add it to the revision description and try one last time.
Addresses the same issue as the following abandoned revision: D104391.
Rewrite leading declarative allocations so they are nested within their respective executable allocate directive
Original:
```
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPExecutableAllocate
```
After rewriting:
```
ExecutionPartConstruct -> OpenMPExecutableAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
```
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D148409
Addresses the same issue as the following abandoned revision: D104391.
Rewrite leading declarative allocations so they are nested within their respective executable allocate directive
Original:
```
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPExecutableAllocate
```
After rewriting:
```
ExecutionPartConstruct -> OpenMPExecutableAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
```
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D148409
Initial support for USE_DEVICE_PTR clause on OMP TARGET DATA directive.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D148254
Error only applies if it is a whole array. Page 157 in OpenMP 5.2
standard.
Reviewed By: TIFitis
Differential Revision: https://reviews.llvm.org/D147142
Issue error if a DO construct associated with a loop does not have
loop control. Currently, it is issued only for the loop immediately
following the loop construct. This patch extends it to cases like
collapse where there is more than one loop associated. It also fixes
a crash since the existing code always expects loop control.
This is covered in OpenMP 4.5 standard, Section 2.7.1.
"The do-loop cannot be a DO WHILE or a DO loop without loop control."
OpenACC 3.3 covers this indirectly in Section 2.9.1.
The trip count for all loops associated with the collapse clause must
be computable and invariant in all the loops".
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D144290
OpenMP 5.0 adds support for the "requires" directive. This patch adds parser support for it in flang.
Differential revision: https://reviews.llvm.org/D136867
The previous resolve only creates the host associated varaibles for
common block members, but does not replace the original objects with
the new created ones. Fix it and also compute the sizes and offsets
for the host common block members if they are host associated.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D127214
If one tries to compile the attached test case code with flan,
the one will get an internal compiler error on `CHECK(level == 0)`
at the end of `PrivatizeAssociatedLoopIndex` function.
Other compilers (gfortran and nvfortran) build this code just fine.
This change fixes the ICE.
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D132846
