In OpenMP 6.0 a subset of the dependence types is also used in the
`depinfo-modifier` on INIT clause. Make the enum be a common type to
avoid defining separate enum types with mostly identical members.
Use the name `OmpDependenceKind` because the other obvious candidate,
OmpDependenceType, used to be a modifier name in older OpenMP specs.
This adds parsing and lowering of the COMBINER clause. It utilizes the
existing lowering code for combiner-expression to lower the COMBINER
clause as well.
Add two more AST nodes, one for a misplaced end-directive, and one for
an invalid string following the OpenMP sentinel (e.g. "!$OMP XYZ").
Emit error messages when either node is encountered in semantic
analysis.
This patch adds semantics for the `omp fuse` directive in flang, as
specified in OpenMP 6.0. This patch also enables semantic support for
loop sequences which are needed for the fuse directive along with
semantics for the `looprange` clause. These changes are only semantic.
Relevant tests have been added , and previous behavior is retained with
no changes.
---------
Co-authored-by: Ferran Toda <ferran.todacasaban@bsc.es>
Co-authored-by: Krzysztof Parzyszek <Krzysztof.Parzyszek@amd.com>
Flang does not allow the use of Structure Component types inside of
certain OpenMP clauses. While this has been introduced, it seemed that
Structure Component Array Elements were not being captured as they got
embedded in the parse tree. To ensure all structure component types are
identified, a new `HasStructureComponent` evaluate function has been
introduced to walk a Semantics expression, identified where Components
are used within.
This replaces the previous implementation of `CheckStructureComponent`
which just looked for the StructureComponent inside of a DataRef.
Fixes#150830
The ALLOCATE directive has two forms:
- A declarative form with a standalone directive:
```
!$OMP ALLOCATE (variable-list-item...)
```
- An executable form that consists of several directives followed by an
ALLOCATE statement:
```
!$OMP ALLOCATE (variable-list-item...)
!$OMP ALLOCATE (variable-list-item...)
...
ALLOCATE (...)
```
The second form was deprecated in OpenMP 5.2 in favor of the ALLOCATORS
construct.
Since in the parse tree every type corresponding to a directive only
corresponds to a single directive, the executable form is represented by
a sequence of nested OmpAllocateDirectives, e.g.
```
!$OMP ALLOCATE(x)
!$OMP ALLOCATE(y)
ALLOCATE(x, y)
```
will become
```
OmpAllocateDirective
|- ALLOCATE(x) // begin directive
`- OmpAllocateDirective // block
|- ALLOCATE(y) // begin directive
`- ALLOCATE(x, y) // block
```
With this change all AST nodes for directives use
OmpDirectiveSpecification as the directive representation.
For ALLOCATORS and executable ALLOCATE first perform list item checks in
the context of an individual ALLOCATE clause or directive respectively,
then perform "global" checks, e.g. whether all list items are present on
the ALLOCATE statement.
These changes allowed to simplify the checks for presence on ALLOCATE
statement and the use of a predefined allocator.
Additionally, allow variable list item lists to be empty, add a test for
the related spec restriction.
This is a first step towards unifying OpenMPDeclarativeAllocate and
OpenMPExecutableAllocate into a single directive.
OpenMP 5.0 and 5.1 allowed the ALLOCATE directive to appear in two
forms, declarative and executable. The syntax of an individual directive
was the same in both cases, but the semantic restrictions were slightly
different.
- Update the semantic checks to reflect the different restrictions,
gather them in a single function.
- Improve test for the presence of a TARGET region, add a check for
REQUIRES directive.
- Update tests.
Introduce a stack of scopes to OmpStructureChecker for scoping units,
plus function/subroutine entries in interfaces.
This will help with applying and locating properties introduced by
declarative or informational directives (e.g. DECLARE_TARGET, REQUIRES),
which are stored as flags on the corresponding symbols.
Replace more parse tree references to "thing" and "value()" with usage
of the parser::Unwrap<> template function.
Add parser::UnwrapRef<> as an alias for DEREF(Unwrap<>()).
Use ScalarIntConstantExpr in the parse tree instead of ScalarIntExpr.
This will still parse a general expression, but the semantic checker for
expressions will automatically perfom a test for whether the value is
constant or not.
Use that instead of manual checks, it will make diagnostics more
uniform. There is no functional change other than that.
OpenMP 6.0 added an optional logical parameter to the requirement
clauses (except ATOMIC_DEFAULT_MEM_ORDER) to indicate whether the clause
should take effect or not. The parameter defaults to true if not
specified.
The parameter value is a compile-time constant expression, but it may
require folding to get the final value. Since name resolution happens
before folding, the argument expression needs to be analyzed by hand.
The determination of the value needs to happen during name resolution
because the requirement directives need to be available through module
files (and the module reader doesn't to semantic checks beyond name
resolution).
Audit the use of std::optional<bool> as a tri-state logical value in
flang, correct a couple cases that need ".value_or()", add some explicit
".has_value()" calls, and document the possible pitfalls.
Add support for the standalone OpenMP tile construct:
```f90
!$omp tile sizes(...)
DO i = 1, 100
...
```
This is complementary to #143715 which added support for the tile
construct as part of another loop-associated construct such as
worksharing-loop, distribute, etc.
This change implements the fuse directive, `#pragma omp fuse`, as specified in the OpenMP 6.0, along with the `looprange` clause in clang.
This change also adds minimal stubs so flang keeps compiling (a full implementation in flang of this directive is still pending).
---------
Co-authored-by: Roger Ferrer Ibanez <roger.ferrer@bsc.es>
This verifies the "structural" restrictions on constructs encountered in
a TASKGRAPH construct.
There are also restrictions that apply to list items, specifically in
the following contexts:
- a list item on a clause on a replayable construct,
- data-sharing attributes for a variable on a replayable construct.
These restrictions are not verified, because that would require knowing
which clauses (on a potential compound directive) apply to the task-
generating construct of interest. This information is not available
during semantic checks.
Since ODS doesn't store a list of OmpObjects (i.e. not as
OmpObjectList), some semantics-checking functions needed to be updated
to operate on a single object at a time.
