Parse the locator list in OmpDependClause as an OmpObjectList (instead
of a list of Designators). When a common block appears in the locator
list, show an informative message.
Implement resolving symbols in DependSinkVec in a dedicated visitor
instead of having a visitor for OmpDependClause.
Resolve unresolved names common blocks in OmpObjectList.
Minor changes to the code organization:
- rename OmpDependenceType to OmpTaskDependenceType (to follow 5.2
terminology),
- rename Depend::WithLocators to Depend::DepType,
- add comments with more detailed spec references to parse-tree.h.
---------
Co-authored-by: Kiran Chandramohan <kiran.chandramohan@arm.com>
Implement parsing of the AFFINITY clause on TASK construct, conversion
from the parser class to omp::Clause.
Lowering to HLFIR is unsupported, a TODO message is displayed.
Define `OmpIteratorSpecifier` and `OmpIteratorModifier` parser classes,
and add parsing for them. Those are reusable between any clauses that
use iterator modifiers.
Add support for iterator modifiers to the MAP clause up to lowering,
where a TODO message is emitted.
The convention is to use enum names that match the source spelling (up
to upper/lower case), including names with underscores.
Remove the special case from unparser, update tests.
This commit adds parsing of type modifiers for the MAP clause: CLOSE,
OMPX_HOLD, and PRESENT. The support for ALWAYS has already existed.
The new modifiers are not yet handled in lowering: when present, a TODO
message is emitted and compilation stops.
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).
This patch restores the flang build, which was inadvertently broken by
the patch to implement 'omp assume' support
(a42e515e3a9f3bb4e44389c097b89104d95b9b29).
Thanks to Maxim Kuvyrkov and the Linaro auto-tester for the heads-up.
This typo would unfortunately cause code like the following to ICE,
where common block symbols/names are used in a map clause:
subroutine sb()
implicit none
integer:: b, c
common /var/ b, c
!$omp target map(tofrom: /var/)
b = 1
c = 2
!$omp end target
end subroutine
A compound construct with a list of clauses is broken up into individual
leaf/composite constructs. Each such construct has the list of clauses
that apply to it based on the OpenMP spec.
Each lowering function (i.e. a function that generates MLIR ops) is now
responsible for generating its body as described below.
Functions that receive AST nodes extract the construct, and the clauses
from the node. They then create a work queue consisting of individual
constructs, and invoke a common dispatch function to process (lower) the
queue.
The dispatch function examines the current position in the queue, and
invokes the appropriate lowering function. Each lowering function
receives the queue as well, and once it needs to generate its body, it
either invokes the dispatch function on the rest of the queue (if any),
or processes nested evaluations if the work queue is at the end.
Re-application of ca1bd5995f6ed934f9187305190a5abfac049173 with fixes for
compilation errors.
A compound construct with a list of clauses is broken up into individual
leaf/composite constructs. Each such construct has the list of clauses
that apply to it based on the OpenMP spec.
Each lowering function (i.e. a function that generates MLIR ops) is now
responsible for generating its body as described below.
Functions that receive AST nodes extract the construct, and the clauses
from the node. They then create a work queue consisting of individual
constructs, and invoke a common dispatch function to process (lower) the
queue.
The dispatch function examines the current position in the queue, and
invokes the appropriate lowering function. Each lowering function
receives the queue as well, and once it needs to generate its body, it
either invokes the dispatch function on the rest of the queue (if any),
or processes nested evaluations if the work queue is at the end.
Accept the reduction modifier in the Flang parser. Issue a TODO message
during lowering.
OpenMP 5.0 introduced the reduction modifier. Details can be seen in
2.19.5.4 reductionClause.
OpenMP 5.2 relevant section is 5.5.8reductionClause.
This will help remove some of the parser errors highlighted in the
following post and also bring it to a well defined behaviour (produce
TODO errors for unsupported features, do not crash).
https://discourse.llvm.org/t/proposal-rename-flang-new-to-flang/69462/60
The clause templates defined in ClauseT.h were originally based on
flang's parse tree nodes. Since those representations are going to be
reused for clang (together with the clause splitting code), it makes
sense to separate them from flang, and instead have them based on the
actual OpenMP spec (v5.2).
The member names in the templates follow the naming presented in the
spec, and the representation (e.g. members) is derived from the clause
definitions as described in the spec.
Since the representations of some clauses has changed (while preserving
the information), the current code using the clauses (especially the
code converting parser::OmpClause to omp::Clause) needs to be adjusted.
This patch does not make any functional changes.
…essor
Rename `findRepeatableClause` to `findRepeatableClause2`, and make the
new `findRepeatableClause` operate on new `omp::Clause` objects.
Leave `Map` unchanged, because it will require more changes for it to
work.
[Clause representation 3/6]
Temporarily rename old clause list to `clauses2`, old clause iterator to
`ClauseIterator2`.
Change `findUniqueClause` to iterate over `omp::Clause` objects, modify
all handlers to operate on 'omp::clause::xyz` equivalents.
[Clause representation 2/6]
The new set of classes representing OpenMP classes mimics the contents
of parser::OmpClause, but differs in a few aspects:
- it can be easily created, copied, etc.
- is based on semantics::SomeExpr instead of parser objects.
This set of classes is geared towards a language-agnostic representation
of OpenMP clauses. While the class members are still based on flang's
`parser::OmpClause`, the classes themselves are actually C++ templates
parameterized with types essential to represent necessary information.
The two parameters are
- `IdType`: the type that can represent object's identity (for flang it
will be `semantics::Symbol *`),
- `ExprType`: the type that can represent expressions, arithmetic and
object references (`semantics::MaybeExpr` in flang).
The templates are defined in a namespace `tomp` (to distinguish it from
`omp`).
This patch introduces file "Clauses.cpp", which contains instantiations
of all of the templates for flang. The instantiations are members of
namespace `omp`, and include an all-encompassing variant class
`omp::Clause`, which is the analog of `parser::OmpClause`.
The class `OmpObject` is represented by `omp::Object`, which contains
the symbol associated with the object, and `semantics::MaybeExpr`
representing the designator for the symbol reference. For each specific
clause in the variant `parser::OmpClause`, there exists a `make`
function that will generate the corresponding `omp::Clause` from it. The
intent was to use the make functions as variant visitors. The creation
of a clause instance would then follow the pattern:
```
omp::Clause clause = std::visit([](auto &&s) { return make(s, semaCtx); }, parserClause.u);
```
If a new clause `foo` is added in the future, then:
- a new template `tomp::FooT` representing the clause needs to be added
to ClauseT.h,
- a new instance needs to be created in flang, this can be as simple as
`using Foo = tomp::FooT<...>`,
- a new make function needs to be implemented to create object of class
Foo from `parser::OmpClause::Foo`.
This patch only introduces the new classes, they are not yet used
anywhere.
[Clause representation 1/6]
