The structure is
- OmpBeginDirective (aka OmpDirectiveSpecification)
- Block
- optional<OmpEndDirective> (aka optional<OmpDirectiveSpecification>)
The OmpBeginDirective and OmpEndDirective are effectively different
names for OmpDirectiveSpecification. They exist to allow the semantic
analyses to distinguish between the beginning and the ending of a block
construct without maintaining additional context.
The actual changes are in the parser: parse-tree.h and openmp-parser.cpp
in particular. The rest is simply changing the way the directive/clause
information is accessed (typically for the simpler).
All standalone and block constructs now use OmpDirectiveSpecification to
store the directive/clause information.
The OpenMPSectionConstruct corresponds to the `!$omp section` directive,
but there is nothing in the AST node that stores the directive
information. Even though the only possibility (at the moment) is
"section" without any clauses, for improved generality it is helpful to
have that information anyway.
Block-associated constructs have, as their body, either a strictly- or a
loosely-structured block. In the former case the end-directive is
optional.
The existing parser required the end-directive to be present in all
cases.
Note:
The definitions of these blocks in the OpenMP spec exclude cases where
the block contains more than one construct, and the first one is
BLOCK/ENDBLOCK. For example, the following is invalid:
```
!$omp target
block ! This cannot be a strictly-structured block, but
continue ! a loosely-structured block cannot start with
endblock ! BLOCK/ENDBLOCK
continue !
!$omp end target
```
A check for character substrings masquerading as array sections was
using expression analyzer on the array base. When this array happened to
be an assumed-size array, the analyzer emitted a semantic error that did
not correspond to any issue with the source code.
To avoid that, check whether the object is an assumed-size array before
using the expression analyzer on it.
While at it, replace the call to GetShape with a simple check for rank,
since that's the only information needed.
Fixes https://github.com/llvm/llvm-project/issues/150297
OpenMP 6.0 has changed the modifiers on the MAP clause. Previous patch
has introduced parsing support for them. This patch introduces
processing of the new forms in semantic checks and in lowering. This
only applies to existing modifiers, which were updated in the 6.0 spec.
Any of the newly introduced modifiers (SELF and REF) are ignored.
The following code is now accepted:
```
module m
end
program m
use m
end
```
The PROGRAM name doesn't really have an effect on the compilation
result, so it shouldn't result in symbol name conflicts.
This change makes the main program symbol name all uppercase in the
cooked character stream. This makes it distinct from all other symbol
names that are all lowercase in cooked character stream.
Modified the tests that were checking for lower case main program name.
Dispatch is the last construct (after ATOMIC and ALLOCATORS) where the
associated block requires a specific form.
Using OmpDirectiveSpecification for the begin and the optional end
directives will make the structure of all block directives more uniform.
The ALLOCATORS construct is one of the few constructs that require a
special form of the associated block.
Convert the AST node to use OmpDirectiveSpecification for the directive
and the optional end directive, and to use parser::Block as the body:
the form of the block is checked in the semantic checks (with a more
meaningful message).
OpenMP 6.0 introduced alternative spelling for some directives, with the
previous spellings still allowed.
Warn the user when a new spelling is encountered with OpenMP version set
to an older value.
Create these new files in flang/lib/Semantics:
openmp-utils.cpp/.h - Common utilities
check-omp-atomic.cpp - Atomic-related checks
check-omp-loop.cpp - Loop constructs/clauses
check-omp-metadirective.cpp - Metadirective-related checks
Update lists of included headers, std in particular.
---------
Co-authored-by: Jack Styles <jack.styles@arm.com>
In OpenMP Version 5.1, the tile and unroll directives were added. When
using these directives, it is possible to nest them within other OpenMP
Loop Constructs. This patch enables the semantics to allow for this
behaviour on these specific directives. Any nested loops will be stored
within the initial Loop Construct until reaching the DoConstruct itself.
Relevant tests have been added, and previous behaviour has been retained
with no changes.
See also, #110008
Some new code was added to flang/Semantics that only depends on
facilities in flang/Evaluate. Move it into Evaluate and clean up some
minor stylistic problems.
The previous approach rewrote the atomic constructs in the AST based on
the REQUIRES ATOMIC_DEFAULT_MEM_ORDER directives. The new approach
checks for incorrect uses of REQUIRED ADMO in the semantic analysis, and
applies it in lowering, eliminating the need for a separate
tree-rewriting procedure.
The message "The atomic variable x should occur exactly once among the
arguments of the top-level [...] operator" was intended to convey that
(1) an atomic variable should be an argument, and (2) it should be
exactly one of the arguments. However, the wording turned out to be
sowing confusion instead.
Rework the corresponding check, and emit an individual error message for
each problematic situation:
- "atomic variable cannot be a proper subexpression of an argument",
- "atomic variable should appear as an argument",
- "atomic variable should be exactly one of the arguments".
Fixes https://github.com/llvm/llvm-project/issues/144599
As part of OpenMP Version 5.1, support for the `indirect` clause was
added for the `declare target` directive. This clause should follow an
`enter` clause, and allows procedure calls to be done indirectly through
OpenMP.
This adds Parsing support for the clause, along with semantics checks.
Currently, lowering for the clause is not supported so a TODO message
will be outputted to the user. It also performs version checking as
`indirect` is only support in OpenMP 5.1 or greater.
See also: #110008
Fixes#142404
The parser can't tell the difference between array indexing and a
substring: that has to be done in semantics once we have types.
Substrings can only be in the form string([lower]:[higher]) not
string(index) or string(lower:higher:step). I added semantic checks to
catch this for the DEPEND clause.
This patch also adds lowering for correct substrings and for complex
part references.
The parser will accept a wide variety of illegal attempts at forming an
ATOMIC construct, leaving it to the semantic analysis to diagnose any
issues. This consolidates the analysis into one place and allows us to
produce more informative diagnostics.
The parser's outcome will be parser::OpenMPAtomicConstruct object
holding the directive, parser::Body, and an optional end-directive. The
prior variety of OmpAtomicXyz classes, as well as OmpAtomicClause have
been removed. READ, WRITE, etc. are now proper clauses.
The semantic analysis consistently operates on "evaluation"
representations, mainly evaluate::Expr (as SomeExpr) and
evaluate::Assignment. The results of the semantic analysis are stored in
a mutable member of the OpenMPAtomicConstruct node. This follows a
precedent of having `typedExpr` member in parser::Expr, for example.
This allows the lowering code to avoid duplicated handling of AST nodes.
Using a BLOCK construct containing multiple statements for an ATOMIC
construct that requires multiple statements is now allowed. In fact, any
nesting of such BLOCK constructs is allowed.
This implementation will parse, and perform semantic checks for both
conditional-update and conditional-update-capture, although no MLIR will
be generated for those. Instead, a TODO error will be issues prior to
lowering.
The allowed forms of the ATOMIC construct were based on the OpenMP 6.0
spec.
Two recently-added functions in Semantics/tools.h need some cleaning up
to conform to the coding style of the project. One of them should
actually be in Parser/tools.{h,cpp}, the other doesn't need to be
defined in the header.
This adds another puzzle piece for the support of OpenMP DECLARE
REDUCTION functionality.
This adds support for operators with derived types, as well as declaring
multiple different types with the same name or operator.
A new detail class for UserReductionDetials is introduced to hold the
list of types supported for a given reduction declaration.
Tests for parsing and symbol generation added.
Declare reduction is still not supported to lowering, it will generate a
"Not yet implemented" fatal error.
Fixes#141306Fixes#97241Fixes#92832Fixes#66453
---------
Co-authored-by: Mats Petersson <mats.petersson@arm.com>
If a "TASK DEPEND" clause is not given a valid task dependece type
modifier, the semantic checks for the clause will result in an ICE
because they assume that such modifiers will be present. Check whether
the modifiers are present and show an appropriate error instead of
crashing the compiler if they are not.
Fixes llvm#133678.
Signed-off-by: Kajetan Puchalski <kajetan.puchalski@arm.com>
Even though the spec (version 5.2) prohibits strcuture components from
being specified in `depend` clauses, this restriction is not sensible.
This PR rectifies the issue by lifting that restriction and allowing
structure components in `depend` clauses (which is allowed by OpenMP
6.0).
The check if the arguments are variable list items was missing, leading
to a crash in lowering in some invalid situations.
This fixes the first testcase reported in
https://github.com/llvm/llvm-project/issues/141481
Fix a crash caused by an invalid expression in the atomic capture
clause, due to the `checkForSymbolMatch` function not accounting for
`GetExpr` potentially returning null.
Fix https://github.com/llvm/llvm-project/issues/139884
I think this was denied by accident in
68180d8d16.
Flush of a common block is allowed by the standard on my reading. It is
not allowed by classic-flang but is supported by gfortran and ifx.
This doesn't need any lowering changes. The LLVM translation ignores the
flush argument list because the openmp runtime library doesn't support
flushing specific data.
Depends upon https://github.com/llvm/llvm-project/pull/139522. Ignore
the first commit in this PR.
Some directive names can be used as clauses, for example in "cancel". In
case where a directive name is misplaced, it could be interpreted as a
clause.
Verify that such uses are valid, and emit a diagnostic message if not.
Fixes https://github.com/llvm/llvm-project/issues/138224
If a symbol is not declared, check-omp-structure hits an assert. It
should be safe to treat undeclared symbols as "not from a block", as
they would have to be declared to be in a block...
Adding simple test to confirm it gives error messages, not crashing.
This should fix issue #131655 (there is already a check for symbol being
not null in the code identified in the ticket).
Fixes:
- Add semantic checks along with the tests
- Move the detach clause to allowedOnceClauses list in Task construct
Restrictions:\
OpenMP 5.0: Task construct
- At most one detach clause can appear on the directive.
- If a detach clause appears on the directive, then a mergeable clause
cannot appear on the same directive.
OpenMP 5.2: Detach contruct
- If a detach clause appears on a directive, then the encountering task
must not be a final task.
- A variable that appears in a detach clause cannot appear as a list
item on a data-environment attribute clause on the same construct.
- A variable that is part of another variable (as an array element or a
structure element) cannot appear in a detach clause.
- event-handle must not have the POINTER attribute.
Support is added for parsing. Basic semantics support is added to
forward the code to Lowering. Lowering will emit a TODO error. Detailed
semantics checks and lowering is further work.
The UPDATE clause can be specified on both ATOMIC and DEPOBJ directives.
Currently, the ATOMIC directive has its own handling of it, and the
definition of the UPDATE clause only supports its use in the DEPOBJ
directive, where it takes a dependence-type as an argument.
The UPDATE clause on the ATOMIC directive may not have any arguments.
Since the implementation of the ATOMIC construct will be modified to use
the standard handling of clauses, the definition of UPDATE should
reflect that.
Add following semantic checks for ALLOCATE directive as per OpenMP 6.0
standard.
- List item in ALLOCATE directive must not be a dummy argument
- List item in ALLOCATE directive must not have POINTER attribute
- List item in ALLOCATE directive must not be a associate name
The OmpAtomicClause is a variant of a few specific clauses that are used
on the ATOMIC construct. The HINT clause, however, was represented as a
generic OmpClause, which somewhat complicated the analysis of an
OmpAtomicClause.
Introduce OmpHintClause to represent the contents of the HINT clause,
and use it on OmpAtomicClause similarly to how OmpFailClause is used.
NOWAIT was a tricky one because the clause can be on either the start or
the end directive. I couldn't find a convenient way to access the end
directive from the CANCEL directive nested inside of the construct, but
there are convenient ways to access the start directive. I have added a
list to the start directive context containing the clauses from the end
directive.
I'm not sure why strides were not allowed in array sections: the stride
is explicitly allowed by the standard from the first version where array
sections were introduced. The limitation is that the stride must not be
negative.
Here I have added the check for a negative stride and updated the test
for a zero length section to take account of the stride.
The `OmpDirectiveSpecification` contains directive name, the list of
arguments, and the list of clauses. It was introduced to store the
directive specification in METADIRECTIVE, and could be reused everywhere
a directive representation is needed.
In the long term this would unify the handling of common directive
properties, as well as creating actual constructs from METADIRECTIVE by
linking the contained directive specification with any associated user
code.
Adds Parser and Semantic Support for the below construct and clauses:
- Interop Construct
- Init Clause
- Use Clause
Note:
The other clauses supported by Interop Construct such as Destroy, Use,
Depend and Device are added already.
