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.
This patch implements support for the VECTOR ALWAYS directive, which
forces
vectorization to occurr when possible regardless of a decision by the
cost
model. This is done by adding an attribute to the branch into the loop
in LLVM
to indicate that the loop should always be vectorized.
This patch only implements this directive on plan structured do loops
without labels. Support for unstructured loops and array
expressions is planned for future patches.
This CDEFINED keyword extension to a language-binding-spec signifies
that static storage for an interoperable variable will be allocated
outside of Fortran, probably by a C/C++ external object definition.
Derived from #92480. This PR supports parsing of the DO CONCURRENT
REDUCE clause in Fortran 2023. Following the style of the OpenMP parser
in MLIR, the front end accepts both arbitrary operations and procedures
for the REDUCE clause. But later Semantics can notify type errors and
resolve procedure names.
omp masked directive in OpenMP 5.2 allows to specify code regions which
are expected to be executed by thread ids specified by the programmer.
Filter clause of the directive allows to specify the thread id. This
change adds the parsing support for the directive
A !$CUF KERNEL DO directive is allowed to have advisory REDUCE clauses
similar to those in OpenACC and DO CONCURRENT. Parse and represent them.
Semantic validation will follow.
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
Add `notify-type` to `iso_fortran_env` module. Add `notify-wait-stmt` to
the parser and add checks for constraints on the statement, `C1177` and
`C1178`, from the Fortran 2023 standard. Add three semantics tests for
`notify-wait-stmt`.
Fortran requires that a DO construct with a construct name end with an
END DO statement bearing the same name. This is true even if the DO
construct begins with a label DO statement; e.g., "constrName: do 10
j=1,10" must end with "10 end do constrName".
The compiler presently basically ignores construct names that appear on
label DO statements, because only non-label DO statements can be parsed
as DO constructs. This causes us to miss some errors, and (worse) breaks
the usage of the construct name on CYCLE and EXIT statements.
To fix this, this patch changes the parse tree and parser so that a DO
construct name on a putative label DO statement causes it to be parsed
as a "non-label" DO statement... with a label. Only true old-style
labeled DO statements without construct names are now parsed as such.
I did not change the class name NonLabelDoStmt -- it's widely used
across the front-end, and is the name of a production in the standard's
grammar. But now it basically means DoConstructDoStmt.
Fixes https://github.com/llvm/llvm-project/issues/67283.
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
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
unparsing for the bind clause was adding extra
parenthesis. This patch fixes that.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D158210
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
Add parsing supprot for dim in gang clause
Depends on D151971
Reviewed By: razvanlupusoru, jeanPerier
Differential Revision: https://reviews.llvm.org/D151972
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
Begin upstreaming of CUDA Fortran support in LLVM Flang.
This first patch implements parsing for CUDA Fortran syntax,
including:
- a new LanguageFeature enum value for CUDA Fortran
- driver change to enable that feature for *.cuf and *.CUF source files
- parse tree representation of CUDA Fortran syntax
- dumping and unparsing of the parse tree
- the actual parsers for CUDA Fortran syntax
- prescanning support for !@CUF and !$CUF
- basic sanity testing via unparsing and parse tree dumps
... along with any minimized changes elsewhere to make these
work, mostly no-op cases in common::visitors instances in
semantics and lowering to allow them to compile in the face
of new types in variant<> instances in the parse tree.
Because CUDA Fortran allows the kernel launch chevron syntax
("call foo<<<blocks, threads>>>()") only on CALL statements and
not on function references, the parse tree nodes for CallStmt,
FunctionReference, and their shared Call were rearranged a bit;
this caused a fair amount of one-line changes in many files.
More patches will follow that implement CUDA Fortran in the symbol
table and name resolution, and then semantic checking.
Differential Revision: https://reviews.llvm.org/D150159
The following PowerPC vector type syntax is added:
VECTOR ( element-type-spec )
where element-type-sec is integer-type-spec, real-type-sec or unsigned-type-spec.
Two opaque types (__VECTOR_PAIR and __VECTOR_QUAD) are also added.
A finite set of functionalities are implemented in order to support the new types:
1. declare objects
2. declare function result
3. declare type dummy arguments
4. intrinsic assignment between the new type objects (e.g. v1=v2)
5. reference functions that return the new types
Submit on behalf of @tislam @danielcchen
Authors: @tislam @danielcchen
Differential Revision: https://reviews.llvm.org/D150876
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
Implement semantics for the IGNORE_TKR directive as it is interpreted
by the PGI / NVFORTRAN compiler.
Differential Revision: https://reviews.llvm.org/D148643
This patch adds parser suppert for the device_type clause used by the Declare Target directive.
Differential Revision: https://reviews.llvm.org/D143671
Rework some recent changes to the ENUM_CLASS() macro so that
all of the construction of enumerator-to-name string mapping
data structures is again performed at compilation time.
Differential Revision: https://reviews.llvm.org/D137859
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
This patch adds support for the device clause on `Target` directive.
Device clause was added in OpenMP specification version 4.5 to
create a device data environment for the extent of a region. On
target construct, the device expression be either be `ancestor`
(taking after the parent) or assign a new `device_num`.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D126441
A type-param-inquiry of %KIND or %LEN applies to a designator, and
so must also be allowed for a substring. F18 presently (mis)parses
instances of a type-param-inquiry as structure component references
and then fixes them in expression semantics when types are known and
we can distinguish them. But when the base of a type-param-inquiry is
a substring of an array element, as in "charArray(i)(j:k)%len",
parsing fails.
Adjust the grammar to parse these cases, and extend expression semantics
to process the new production.
Differential Revision: https://reviews.llvm.org/D130375
OpenMP 5.0 adds a new clause `in_reduction` on OpenMP directives.
This patch adds parser support for the same.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D124156
Adds flang/include/flang/Common/log2-visit.h, which defines
a Fortran::common::visit() template function that is a drop-in
replacement for std::visit(). Modifies most use sites in
the front-end and runtime to use common::visit().
The C++ standard mandates that std::visit() have O(1) execution
time, which forces implementations to build dispatch tables.
This new common::visit() is O(log2 N) in the number of alternatives
in a variant<>, but that N tends to be small and so this change
produces a fairly significant improvement in compiler build
memory requirements, a 5-10% improvement in compiler build time,
and a small improvement in compiler execution time.
Building with -DFLANG_USE_STD_VISIT causes common::visit()
to be an alias for std::visit().
Calls to common::visit() with multiple variant arguments
are referred to std::visit(), pending further work.
This change is enabled only for GCC builds with GCC >= 9;
an earlier attempt (D122441) ran into bugs in some versions of
clang and was reverted rather than simply disabled; and it is
not well tested with MSVC. In non-GCC and older GCC builds,
common::visit() is simply an alias for std::visit().
For parameterized derived type component initializers whose
expressions' types depend on parameter values, f18's current
scheme of analyzing the initialization expression once during
name resolution fails. For example,
type :: pdt(k)
integer, kind :: k
real :: component = real(0.0, kind=k)
end type
To handle such cases, it is necessary to re-analyze the parse
trees of these initialization expressions once for each distinct
initialization of the type.
This patch adds code to wipe an expression parse tree of its
typed expressions, and update those of its symbol table pointers
that reference type parameters, and then re-analyze that parse
tree to generate the properly typed component initializers.
Differential Revision: https://reviews.llvm.org/D123728
