[flang][OpenMP][OpenACC] remove libEvaluate dependency in passes (#123784)

Move OpenACC/OpenMP helpers from Lower/DirectivesCommon.h that are also
used in OpenACC and OpenMP mlir passes into a new

[flang][OpenMP][OpenACC] remove libEvaluate dependency in passes (#123784)

Move OpenACC/OpenMP helpers from Lower/DirectivesCommon.h that are also
used in OpenACC and OpenMP mlir passes into a new
Optimizer/Builder/DirectivesCommon.h so that parser and evaluate headers
are not included in Optimizer libraries (this both introduce
compile-time and link-time pointless overheads).

This should fix https://github.com/llvm/llvm-project/issues/123377

show more ...

Re-apply (#117867): [flang][OpenMP] Implicitly map allocatable record fields (#120374)

This re-applies #117867 with a small fix that hopefully prevents build
bot failures. The fix is avoiding `dyn_

Re-apply (#117867): [flang][OpenMP] Implicitly map allocatable record fields (#120374)

This re-applies #117867 with a small fix that hopefully prevents build
bot failures. The fix is avoiding `dyn_cast` for the result of
`getOperation()`. Instead we can assign the result to `mlir::ModuleOp`
directly since the type of the operation is known statically (`OpT` in
`OperationPass`).

show more ...

Revert "[flang][OpenMP] Implicitly map allocatable record fields (#117867)" (#120360)

[flang][OpenMP] Implicitly map allocatable record fields (#117867)

This is a starting PR to implicitly map allocatable record fields.

This PR contains the following changes:
1. Re-purposes some

[flang][OpenMP] Implicitly map allocatable record fields (#117867)

This is a starting PR to implicitly map allocatable record fields.

This PR contains the following changes:
1. Re-purposes some of the utils used in `Lower/OpenMP.cpp` so that
these utils work on the `mlir::Value` level rather than the
`semantics::Symbol` level. This takes one step towards to enabling
MLIR passes to more easily do some lowering themselves (e.g. creating
`omp.map.bounds` ops for implicitely caputured data like this PR
does).
2. Adds support for implicitely capturing and mapping allocatable fields
in record types.

There is quite some distant to still cover to have full support for
this. I added a number of todos to guide further development.

Co-authored-by: Andrew Gozillon <andrew.gozillon@amd.com>

Co-authored-by: Andrew Gozillon <andrew.gozillon@amd.com>

show more ...

[Flang][OpenMP] Derived type explicit allocatable member mapping (#113557)

This PR is one of 3 in a PR stack, this is the primary change set which
seeks to extend the current derived type explicit

[Flang][OpenMP] Derived type explicit allocatable member mapping (#113557)

This PR is one of 3 in a PR stack, this is the primary change set which
seeks to extend the current derived type explicit member mapping support
to handle descriptor member mapping at arbitrary levels of nesting. The
PR stack seems to do this reasonably (from testing so far) but as you
can create quite complex mappings with derived types (in particular when
adding allocatable derived types or arrays of allocatable derived types)
I imagine there will be hiccups, which I am more than happy to address.
There will also be further extensions to this work to handle the
implicit auto-magical mapping of descriptor members in derived types and
a few other changes planned for the future (with some ideas on
optimizing things).

The changes in this PR primarily occur in the OpenMP lowering and the
OMPMapInfoFinalization pass.

In the OpenMP lowering several utility functions were added or extended
to support the generation of appropriate intermediate member mappings
which are currently required when the parent (or multiple parents) of a
mapped member are descriptor types. We need to map the entirety of these
types or do a "deep copy" for lack of a better term, where we map both
the base address and the descriptor as without the copying of both of
these we lack the information in the case of the descriptor to access
the member or attach the pointers data to the pointer and in the latter
case we require the base address to map the chunk of data. Currently we
do not segment descriptor based derived types as we do with regular
non-descriptor derived types, we effectively map their entirety in all
cases at the moment, I hope to address this at some point in the future
as it adds a fair bit of a performance penalty to having nestings of
allocatable derived types as an example. The process of mapping all
intermediate descriptor members in a members path only occurs if a
member has an allocatable or object parent in its symbol path or the
member itself is a member or allocatable. This occurs in the
createParentSymAndGenIntermediateMaps function, which will also generate
the appropriate address for the allocatable member within the derived
type to use as a the varPtr field of the map (for intermediate
allocatable maps and final allocatable mappings). In this case it's
necessary as we can't utilise the usual Fortran::lower functionality
such as gatherDataOperandAddrAndBounds without causing issues later in
the lowering due to extra allocas being spawned which seem to affect the
pointer attachment (at least this is my current assumption, it results
in memory access errors on the device due to incorrect map information
generation). This is similar to why we do not use the MLIR value
generated for this and utilise the original symbol provided when mapping
descriptor types external to derived types. Hopefully this can be
rectified in the future so this function can be simplified and more
closely aligned to the other type mappings. We also make use of
fir::CoordinateOp as opposed to the HLFIR version as the HLFIR version
doesn't support the appropriate lowering to FIR necessary at the moment,
we also cannot use a single CoordinateOp (similarly to a single GEP) as
when we index through a descriptor operation (BoxType) we encounter
issues later in the lowering, however in either case we need access to
intermediate descriptors so individual CoordinateOp's aid this
(although, being able to compress them into a smaller amount of
CoordinateOp's may simplify the IR and perhaps result in a better end
product, something to consider for the future).

The other large change area was in the OMPMapInfoFinalization pass,
where the pass had to be extended to support the expansion of box types
(or multiple nestings of box types) within derived types, or box type
derived types. This requires expanding each BoxType mapping from one
into two maps and then modifying all of the existing member indices of
the overarching parent mapping to account for the addition of these new
members alongside adjusting the existing member indices to support the
addition of these new maps which extend the original member indices (as
a base address of a box type is currently considered a member of the box
type at a position of 0 as when lowered to LLVM-IR it's a pointer
contained at this position in the descriptor type, however, this means
extending mapped children of this expanded descriptor type to
additionally incorporate the new member index in the correct location in
its own index list). I believe there is a reasonable amount of comments
that should aid in understanding this better, alongside the test
alterations for the pass.

A subset of the changes were also aimed at making some of the utilities
for packing and unpacking the DenseIntElementsAttr containing the member
indices shareable across the lowering and OMPMapInfoFinalization, this
required moving some functions to the Lower/Support/Utils.h header, and
transforming the lowering structure containing the member index data
into something more similar to the version used in
OMPMapInfoFinalization. There we also some other attempts at tidying
things up in relation to the member index data generation in the
lowering, some of which required creating a logical operator for the
OpenMP ID class so it can be utilised as a map key (it simply utilises
the symbol address for the moment as ordering isn't particularly
important).

Otherwise I have added a set of new tests encompassing some of the
mappings currently supported by this PR (unfortunately as you can have
arbitrary nestings of all shapes and types it's not very feasible to
cover them all).

show more ...

[Flang][OpenMP] Improve entry block argument creation and binding (#110267)

The main purpose of this patch is to centralize the logic for creating
MLIR operation entry blocks and for binding them t

[Flang][OpenMP] Improve entry block argument creation and binding (#110267)

The main purpose of this patch is to centralize the logic for creating
MLIR operation entry blocks and for binding them to the corresponding
symbols. This minimizes the chances of mixing arguments up for
operations having multiple entry block argument-generating clauses and
prevents divergence while binding arguments.

Some changes implemented to this end are:
- Split into two functions the creation of the entry block, and the
binding of its arguments and the corresponding Fortran symbol. This
enabled a significant simplification of the lowering of composite
constructs, where it's no longer necessary to manually ensure the lists
of arguments and symbols refer to the same variables in the same order
and also match the expected order by the `BlockArgOpenMPOpInterface`.
- Removed redundant and error-prone passing of types and locations from
`ClauseProcessor` methods. Instead, these are obtained from the values
in the appropriate clause operands structure. This also simplifies
argument lists of several lowering functions.
- Access block arguments of already created MLIR operations through the
`BlockArgOpenMPOpInterface` instead of directly indexing the argument
list of the operation, which is not scalable as more entry block
argument-generating clauses are added to an operation.
- Simplified the implementation of `genParallelOp` to no longer need to
define different callbacks depending on whether delayed privatization is
enabled.

show more ...

[flang][OpenMP] Parse lastprivate modifier, add TODO to lowering (#110568)

Parse the lastprivate clause with a modifier. Codegen for it is not yet
implemented.

[OpenMP][Flang] Fix dynamic-extent array mapping (#107247)

This patch fixes the mapping and lowering of arrays with dynamic extents
and adds a new test for the same. The fix discards the incomplete

[OpenMP][Flang] Fix dynamic-extent array mapping (#107247)

This patch fixes the mapping and lowering of arrays with dynamic extents
and adds a new test for the same. The fix discards the incomplete the
dynamic extent information and replacing it with just the base type.
When lowering to llvm later, the bounds information is used instead.

show more ...

[flang][OpenMP] Enable delayed privatization for `omp parallel` by default (#90945)

Flips the delayed privatization switch to be on by default. After the
recent fixes related to delayed privatizat

[flang][OpenMP] Enable delayed privatization for `omp parallel` by default (#90945)

Flips the delayed privatization switch to be on by default. After the
recent fixes related to delayed privatization, the gfortran test suite
runs successfully with delayed privatization turned on by defuault for
`omp parallel`.

show more ...

[Flang] Switch to common::visit more call sites (#90018)

Switch to common::visit more call sites.

Test plan: ninja check-all

[flang][OpenMP] Add `--openmp-enable-delayed-privatization-staging` flag (#94749)

[flang][OpenMP] Make object identity more precise (#94495)

Derived type components may use a given `Symbol` regardless of what
parent objects they are a part of. Because of that, simply using a
sy

[flang][OpenMP] Make object identity more precise (#94495)

Derived type components may use a given `Symbol` regardless of what
parent objects they are a part of. Because of that, simply using a
symbol address is not sufficient to determine object identity.

Make the designator a part of the IdTy. To compare identities, when
symbols are equal (and non-null), compare the designators.

show more ...

[flang][OpenMP] Add `sym()` member function to omp::Object (#94493)

The object identity requires more than just `Symbol`. Don't use `id()`
to get the Symbol associated with the object, becase the r

[flang][OpenMP] Add `sym()` member function to omp::Object (#94493)

The object identity requires more than just `Symbol`. Don't use `id()`
to get the Symbol associated with the object, becase the return value
will need to change. Instead use `sym()` which is added for that reason.

show more ...

[flang][OpenMP] Remove unnecessary `Fortran::` qualification, NFC (#92298)

The `Fortran::` namespace is redundant for all parts of the code in this
PR, except for names of functions in their defini

[flang][OpenMP] Remove unnecessary `Fortran::` qualification, NFC (#92298)

The `Fortran::` namespace is redundant for all parts of the code in this
PR, except for names of functions in their definitions.

show more ...

[flang][OpenMP] Decompose compound constructs, do recursive lowering (#90098)

A compound construct with a list of clauses is broken up into individual
leaf/composite constructs. Each such construct

[flang][OpenMP] Decompose compound constructs, do recursive lowering (#90098)

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.

show more ...

Revert "[flang][OpenMP] Decompose compound constructs, do recursive lowering (#90098)"

It breaks some builds, e.g.
https://lab.llvm.org/buildbot/#/builders/268/builds/13909

This reverts commit ca1b

Revert "[flang][OpenMP] Decompose compound constructs, do recursive lowering (#90098)"

It breaks some builds, e.g.
https://lab.llvm.org/buildbot/#/builders/268/builds/13909

This reverts commit ca1bd5995f6ed934f9187305190a5abfac049173.

show more ...

[flang][OpenMP] Decompose compound constructs, do recursive lowering (#90098)

A compound construct with a list of clauses is broken up into individual
leaf/composite constructs. Each such construct

[flang][OpenMP] Decompose compound constructs, do recursive lowering (#90098)

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.

show more ...

[Flang] Remove deprecated cast style that snuck in during landing of 435e850ba97ab567a14b6c84d2b27cadb771cb27

[Flang][OpenMP][MLIR] Initial derived type member map support

This patch is one in a series of four patches that seeks to refactor
slightly and extend the current record type map support that was
pu

[Flang][OpenMP][MLIR] Initial derived type member map support

This patch is one in a series of four patches that seeks to refactor
slightly and extend the current record type map support that was
put in place for Fortran's descriptor types to handle explicit
member mapping for record types at a single level of depth.

For example, the below case where two members of a Fortran
derived type are mapped explicitly:

''''
type :: scalar_and_array
real(4) :: real
integer(4) :: array(10)
integer(4) :: int
end type scalar_and_array
type(scalar_and_array) :: scalar_arr

!$omp target map(tofrom: scalar_arr%int, scalar_arr%real)
''''

Current cases of derived type mapping left for future work are:
> explicit member mapping of nested members (e.g. two layers of
record types where we explicitly map a member from the internal
record type)
> Fortran's automagical mapping of all elements and nested elements
of a derived type
> explicit member mapping of a derived type and then constituient members
(redundant in Fortran due to former case but still legal as far as I am aware)
> explicit member mapping of a record type (may be handled reasonably, just
not fully tested in this iteration)
> explicit member mapping for Fortran allocatable types (a variation of nested
record types)

This patch seeks to support this by extending the Flang-new OpenMP lowering to
support generation of this newly required information, creating the neccessary
parent <-to-> member map_info links, calculating the member indices and
setting if it's a partial map.

The OMPDescriptorMapInfoGen pass has also been generalized into a map
finalization phase, now named OMPMapInfoFinalization. This pass was extended
to support the insertion of member maps into the BlockArg and MapOperands of
relevant map carrying operations. Similar to the method in which descriptor types
are expanded and constituient members inserted.

Pull Request: https://github.com/llvm/llvm-project/pull/82853

show more ...

[flang][OpenMP] Implement getIterationVariableSymbol helper function,… (#90087)

… NFC

[flang][OpenMP] Move clause/object conversion to happen early, in genOMP (#87086)

This removes the last use of genOmpObjectList2, which has now been
removed.

---------

Co-authored-by: Sergio

[flang][OpenMP] Move clause/object conversion to happen early, in genOMP (#87086)

This removes the last use of genOmpObjectList2, which has now been
removed.

---------

Co-authored-by: Sergio Afonso <safonsof@amd.com>

show more ...

Reapply "[Flang][OpenMP][Lower] NFC: Move clause processing helpers into the ClauseProcessor (#85258)" (#85807)

This patch contains slight modifications to the reverted PR #85258 to
avoid issues wi

Reapply "[Flang][OpenMP][Lower] NFC: Move clause processing helpers into the ClauseProcessor (#85258)" (#85807)

This patch contains slight modifications to the reverted PR #85258 to
avoid issues with constructs containing multiple reduction clauses,
uncovered by a test on the gfortran testsuite.

This reverts commit 9f80444c2e669237a5c92013f1a42b91b5609012.

show more ...

Revert "[Flang][OpenMP][Lower] NFC: Move clause processing helpers into the ClauseProcessor (#85258)"

Reverting due to failing gfortran test.

This reverts commit 2f2f16f32bb2a6c250b19adbc229d9dc3b3

Revert "[Flang][OpenMP][Lower] NFC: Move clause processing helpers into the ClauseProcessor (#85258)"

Reverting due to failing gfortran test.

This reverts commit 2f2f16f32bb2a6c250b19adbc229d9dc3b38640c.

show more ...

[Flang][OpenMP][Lower] NFC: Move clause processing helpers into the ClauseProcessor (#85258)

This patch moves some code in PFT to MLIR OpenMP lowering to the
`ClauseProcessor` class. This is so tha

[Flang][OpenMP][Lower] NFC: Move clause processing helpers into the ClauseProcessor (#85258)

This patch moves some code in PFT to MLIR OpenMP lowering to the
`ClauseProcessor` class. This is so that some behavior that is related
to certain clauses stays within the `ClauseProcessor` and it's not the
caller the one responsible for always doing this when the clause is
present.

show more ...

[flang][OpenMP] Convert repeatable clauses (except Map) in ClauseProc… (#81623)

…essor

Rename `findRepeatableClause` to `findRepeatableClause2`, and make the
new `findRepeatableClause` operate o

[flang][OpenMP] Convert repeatable clauses (except Map) in ClauseProc… (#81623)

…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]

show more ...