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] Add frontend support for ompx_bare clause (#111106)

[flang][OpenMP] Add lowering support for task detach (#119128)

This PR adds lowering task detach to MLIR.

[flang][OpenMP] Add MLIR lowering for `loop ... bind` (#114219)

Extends MLIR lowering support for the `loop` directive by adding
lowering support for the `bind` clause.

Parent PR: https://github

[flang][OpenMP] Add MLIR lowering for `loop ... bind` (#114219)

Extends MLIR lowering support for the `loop` directive by adding
lowering support for the `bind` clause.

Parent PR: https://github.com/llvm/llvm-project/pull/114199, only the
latest commit is relevant to this PR.

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] Process motion clauses in a single call (NFC) (#108046)

This patch removes the template parameter of the
`ClauseProcessor::processMotionClauses()` method and instead processes
both

[Flang][OpenMP] Process motion clauses in a single call (NFC) (#108046)

This patch removes the template parameter of the
`ClauseProcessor::processMotionClauses()` method and instead processes
both `TO` and `FROM` as part of a single call. This also enables moving
the implementation out of the header and makes it simpler for a
follow-up patch to potentially refactor `processMap()`,
`processMotionClauses()`, `processUseDeviceAddr()` and
`processUseDevicePtr()`, and minimize code duplication among these.

show more ...

[Flang][OpenMP] Lowering nontemporal clause to MLIR for SIMD directive (#108339)

Currently, Flang throws a "**not yet implemented: Unhandled clause
NONTEMPORAL in SIMD construct**" error when encou

[Flang][OpenMP] Lowering nontemporal clause to MLIR for SIMD directive (#108339)

Currently, Flang throws a "**not yet implemented: Unhandled clause
NONTEMPORAL in SIMD construct**" error when encountering nontemporal
clause. This patch adds support for this clause in SIMD construct.

show more ...

[MLIR][OpenMP] Automate operand structure definition (#99508)

This patch adds the "gen-openmp-clause-ops" `mlir-tblgen` generator to
produce the structure definitions previously in OpenMPClauseOper

[MLIR][OpenMP] Automate operand structure definition (#99508)

This patch adds the "gen-openmp-clause-ops" `mlir-tblgen` generator to
produce the structure definitions previously in OpenMPClauseOperands.h
automatically from the information contained in OpenMPOps.td and
OpenMPClauses.td.

The original header is maintained to enable the definition of similar
structures that are not directly related to any single `OpenMP_Clause`
or `OpenMP_Op` tablegen definition.

show more ...

[OpenMP]Update use_device_clause lowering (#101703)

This patch updates the use_device_ptr and use_device_addr clauses to use
the mapInfoOps for lowering. This allows all the types that are handle

[OpenMP]Update use_device_clause lowering (#101703)

This patch updates the use_device_ptr and use_device_addr clauses to use
the mapInfoOps for lowering. This allows all the types that are handle
by the map clauses such as derived types to also be supported by the
use_device_clauses.

This is patch 1/2 in a series of patches.

Co-authored-by: Raghu Maddhipatla raghu.maddhipatla@amd.com

show more ...

[Flang][OpenMP] Align map clause generation and fix issue with non-shared allocations for assumed shape/size descriptor types (#97855)

This PR aims to unify the map argument generation behavior acr

[Flang][OpenMP] Align map clause generation and fix issue with non-shared allocations for assumed shape/size descriptor types (#97855)

This PR aims to unify the map argument generation behavior across both
the implicit capture (captured in a target region) and the explicit
capture (process map), currently the varPtr field of the MapInfo for the
same variable will be different depending on how it's captured. This PR
tries to align that across the generations of MapInfoOp in the OpenMP
lowering.

Currently, I have opted to utilise the rawInput (input memref to a HLFIR
DeclareInfoOp) as opposed to the addr field which includes more
information. The side affect of this is that we have to deal with
BoxTypes less often, which will result in simpler maps in these cases.
The negative side affect of this is that we don't have access to the
bounds information through the resulting value, however, I believe the
bounds information we require in our case is still appropriately stored
in the map bounds, and this seems to be the case from testing so far.

The other fix is for cases where we end up with a BoxType argument into
a function (certain assumed shape and sizes cases do this) that has no
fir.ref wrapping it. As we need the Box to be a reference type to
actually utilise the operation to access the base address stored inside
and create the correct mappings we currently generate an intermediate
allocation in these cases, and then store into it, and utilise this as
the map argument, as opposed to the original.

However, as we were not sharing the same intermediate allocation across
all of the maps for a variable, this resulted in errors in certain cases
when detatching/attatching the data e.g. via enter and exit. This PR
adjusts this for cases

Currently we only maintain tracking of all intermediate allocations for
the current function scope, as opposed to module. Primarily as the only
case I am aware of that this is required is in cases where we pass
certain types of arguments to functions (so I opted to minimize the
overhead of the pass for now). It could likely be extended to module
scope if required if we find other cases where it's applicable and
causing issues.

show more ...

[Flang][OpenMP][Lower] Clause lowering cleanup (#103058)

This patch removes the `ClauseProcessor::processDefault` method due to
it having been implemented in
`DataSharingProcessor::collectDefaultS

[Flang][OpenMP][Lower] Clause lowering cleanup (#103058)

This patch removes the `ClauseProcessor::processDefault` method due to
it having been implemented in
`DataSharingProcessor::collectDefaultSymbols` instead.

Also, some `genXyzClauses` functions are updated to avoid triggering
TODO errors for clauses not supported by the corresponding construct and
to keep alphabetical sorting on the order in which clauses are
processed.

show more ...

[MLIR][OpenMP] Create `LoopRelatedClause` (#99506)

This patch introduces a new OpenMP clause definition not defined by the spec.

Its main purpose is to define the `loop_inclusive` (previously "in

[MLIR][OpenMP] Create `LoopRelatedClause` (#99506)

This patch introduces a new OpenMP clause definition not defined by the spec.

Its main purpose is to define the `loop_inclusive` (previously "inclusive",
renamed according to the parent of this PR in the stack) argument of
`omp.loop_nest` in such a way that a followup implementation of a tablegen
backend to automatically generate clause and operation operand structures
directly from `OpenMP_Op` and `OpenMP_Clause` definitions can properly generate
the `LoopNestOperands` structure.

`collapse` clause arguments are also moved into this new definition, as they
represent information on the loop nests being collapsed rather than the
`collapse` clause itself.

show more ...

Adding Changes for invoking Masked Operation (#98423)

PR adds changes to the flang frontend to create the `MaskedOp` when
`masked` directive is used in the input program. Omp masked is
introduced

Adding Changes for invoking Masked Operation (#98423)

PR adds changes to the flang frontend to create the `MaskedOp` when
`masked` directive is used in the input program. Omp masked is
introduced in 5.2 standard and allows a parallel region to be executed
by threads specified by a programmer. This is achieved with the help of
filter clause which helps to specify thread id expected to execute the
region.

Other related PRs:
- [Fortran Parsing and Semantic
Support](https://github.com/llvm/llvm-project/pull/91432) - Merged
- [MLIR Support](https://github.com/llvm/llvm-project/pull/96022/files)
- Merged
- [Lowering Support](https://github.com/llvm/llvm-project/pull/98401) -
Under Review

show more ...

[flang][OpenMP] Lower REDUCTION clause for SECTIONS (#97858)

The tricky bit here is that we need to generate the reduction symbol
mapping inside each of the nested SECTION constructs. This is a bit

[flang][OpenMP] Lower REDUCTION clause for SECTIONS (#97858)

The tricky bit here is that we need to generate the reduction symbol
mapping inside each of the nested SECTION constructs. This is a bit
similar to omp.canonical_loop inside of omp.wsloop, except the SECTION
constructs come from the PFT.

To make this work I moved the lowering of the SECTION constructs inside
of the lowering SECTIONS (where reduction information is still
available). This subverts the normal control flow for OpenMP lowering a
bit.

One alternative option I investigated would be to generate the SECTION
CONSTRUCTS as normal as though there were no reduction, and then to fix
them up after control returns back to genSectionsOp. The problem here is
that the code generated for the section body has the wrong symbol
mapping for the reduction variable, so all of the nested code has to be
patched up. In my prototype version this was even more hacky than what
the solution I settled upon.

show more ...

[Flang][OpenMP] Update flang with changes to the OpenMP dialect (#92524)

This patch applies fixes after the updates to OpenMP clause operands, as
well as updating some tests that were impacted by c

[Flang][OpenMP] Update flang with changes to the OpenMP dialect (#92524)

This patch applies fixes after the updates to OpenMP clause operands, as
well as updating some tests that were impacted by changes to the
ordering or assembly format of some clauses in MLIR.

show more ...

[Flang][OpenMP] Lowering Order clause to MLIR (#96730)

[MLIR][Flang][OpenMP] Implement lowering simd aligned to MLIR (#95198)

Rebased @DominikAdamski patch: https://reviews.llvm.org/D142722

---------

Co-authored-by: Dominik Adamski <dominik.adamsk

[MLIR][Flang][OpenMP] Implement lowering simd aligned to MLIR (#95198)

Rebased @DominikAdamski patch: https://reviews.llvm.org/D142722

---------

Co-authored-by: Dominik Adamski <dominik.adamski@amd.com>
Co-authored-by: Tom Eccles <t@freedommail.info>

show more ...

[Flang][OpenMP][Lower] Add lowering support of OpenMP distribute to MLIR (#67798)

This patch adds support for lowering the OpenMP DISTRIBUTE directive
from PFT to MLIR. It only supports standalone

[Flang][OpenMP][Lower] Add lowering support of OpenMP distribute to MLIR (#67798)

This patch adds support for lowering the OpenMP DISTRIBUTE directive
from PFT to MLIR. It only supports standalone DISTRIBUTE, support for
composite constructs will come in follow-up PRs.

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] NFC: Fix typo in include guard (#91593)

[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][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 ...