History log of /llvm-project/flang/lib/Lower/OpenMP/ClauseProcessor.cpp (Results 1 – 25 of 66)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init
# 662133a2 21-Jan-2025 jeanPerier <jperier@nvidia.com>

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


Revision tags: llvmorg-19.1.7
# d3eb65f1 03-Jan-2025 Kaviya Rajendiran <67495422+kaviya2510@users.noreply.github.com>

[MLIR][OpenMP] Lowering aligned clause to LLVM IR for SIMD directive (#119536)

This patch,
- Added a translation support for aligned clause in SIMD directive by passing the alignment details to "ll

[MLIR][OpenMP] Lowering aligned clause to LLVM IR for SIMD directive (#119536)

This patch,
- Added a translation support for aligned clause in SIMD directive by passing the alignment details to "llvm.assume" intrinsic.
- Updated the insertion point for llvm.assume intrinsic call in "OMPIRBuilder.cpp".
- Added a check in aligned clause MLIR lowering, to ensure that the alignment value must be a power of 2.

show more ...


# cbe583b0 26-Dec-2024 Thirumalai Shaktivel <74826228+Thirumalai-Shaktivel@users.noreply.github.com>

[Flang] Add translation support for MutexInOutSet and InOutSet (#120715)

Implementatoin details:
Both Mutexinoutset and Inoutset is recognized as flag=0x4
and 0x8 respectively, the flags is set t

[Flang] Add translation support for MutexInOutSet and InOutSet (#120715)

Implementatoin details:
Both Mutexinoutset and Inoutset is recognized as flag=0x4
and 0x8 respectively, the flags is set to `kmp_depend_info` and
passed as argument to `__kmpc_omp_task_with_deps` runtime call

show more ...


Revision tags: llvmorg-19.1.6
# 7c9404c2 13-Dec-2024 Ivan R. Ivanov <ivanov.i.aa@m.titech.ac.jp>

[flang][OpenMP] Add frontend support for ompx_bare clause (#111106)


# edc50f39 10-Dec-2024 NimishMishra <42909663+NimishMishra@users.noreply.github.com>

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

This PR adds lowering task detach to MLIR.


Revision tags: llvmorg-19.1.5
# cdbd2287 02-Dec-2024 Krzysztof Parzyszek <Krzysztof.Parzyszek@amd.com>

[flang][OpenMP] Use new modifiers in ALLOCATE clause (#117627)

Again, this simplifies the semantic checks and lowering quite a bit.
Update the check for positive alignment to use a more informative

[flang][OpenMP] Use new modifiers in ALLOCATE clause (#117627)

Again, this simplifies the semantic checks and lowering quite a bit.
Update the check for positive alignment to use a more informative
message, and to highlight the modifier itsef, not the whole clause.
Remove the checks for the allocator expression itself being positive:
there is nothing in the spec that says that it should be positive.

Remove the "simple" modifier from the AllocateT template, since both
simple and complex modifiers are the same thing, only differing in
syntax.

show more ...


# 261a4026 28-Nov-2024 Michael Klemm <michael.klemm@amd.com>

[Flang][OpenMP] Use internal linkage for OpenMP code-gen'ed helper functions (#117911)

When compiling WORKSHARE construct in different compilation units, a
linker error happened, when two equal WOR

[Flang][OpenMP] Use internal linkage for OpenMP code-gen'ed helper functions (#117911)

When compiling WORKSHARE construct in different compilation units, a
linker error happened, when two equal WORKSHARE constructs with a copy
operation have been compiled:

```
/usr/bin/ld: module2.o: in function `_workshare_copy_f64':
FIRModule:(.text+0x0): multiple definition of `_workshare_copy_f64'; module1.o:FIRModule:(.text+0x0): first defined here
```

Reason is that the generate copy function has the wrong linkage:

```
0000000000000000 T _workshare_copy_f64
```

while it should be

```
0000000000000000 t _workshare_copy_f64
```

show more ...


# 52755ac2 25-Nov-2024 Krzysztof Parzyszek <Krzysztof.Parzyszek@amd.com>

[flang][OpenMP] Use new modifier infrastructure for MAP/FROM/TO clauses (#117447)

This removes the specialized parsers and helper classes for these
clauses, namely ConcatSeparated, MapModifiers, an

[flang][OpenMP] Use new modifier infrastructure for MAP/FROM/TO clauses (#117447)

This removes the specialized parsers and helper classes for these
clauses, namely ConcatSeparated, MapModifiers, and MotionModifiers. Map
and the motion clauses are now handled in the same way as all other
clauses with modifiers, with one exception: the commas separating their
modifiers are optional. This syntax is deprecated in OpenMP 5.2.

Implement version checks for modifiers: for a given modifier on a given
clause, check if that modifier is allowed on this clause in the
specified OpenMP version. This replaced several individual checks.

Add a testcase for handling map modifiers in a different order, and for
diagnosing an ultimate modifier out of position.

show more ...


Revision tags: llvmorg-19.1.4
# dcd62070 18-Nov-2024 Kiran Chandramohan <kiran.chandramohan@arm.com>

[Flang][OpenMP] Error gracefully for dependence-type with depobj (#116621)

It also modifies the error message to specify it is the dependence-type
that is not supported.

Resolves the crash in
h

[Flang][OpenMP] Error gracefully for dependence-type with depobj (#116621)

It also modifies the error message to specify it is the dependence-type
that is not supported.

Resolves the crash in
https://github.com/llvm/llvm-project/issues/115647. A fix can come in
later as part of future OpenMP version support.

show more ...


# b4c0ef18 18-Nov-2024 Kareem Ergawy <kareem.ergawy@amd.com>

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


# e508bacc 16-Nov-2024 agozillon <Andrew.Gozillon@amd.com>

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


# f87737f3 11-Nov-2024 Krzysztof Parzyszek <Krzysztof.Parzyszek@amd.com>

[flang][OpenMP] Parse DOACROSS clause (#115396)

Extract the SINK/SOURCE parse tree elements into a separate class
`OmpDoacross`, share them between DEPEND and DOACROSS clauses. Most of
the changes

[flang][OpenMP] Parse DOACROSS clause (#115396)

Extract the SINK/SOURCE parse tree elements into a separate class
`OmpDoacross`, share them between DEPEND and DOACROSS clauses. Most of
the changes in Semantics are to accommodate the new contents of
OmpDependClause, and a mere introduction of OmpDoacrossClause.

There are no semantic checks specifically for DOACROSS.

show more ...


# 29d4d7f6 05-Nov-2024 Krzysztof Parzyszek <Krzysztof.Parzyszek@amd.com>

[flang][OpenMP] Add frontend support for INOUTSET and MUTEXINOUTSET (#114895)

These are additional modifiers of the "task dependence type" kind, which
is already handled by the frontend.


# 1c6ec29b 04-Nov-2024 Krzysztof Parzyszek <Krzysztof.Parzyszek@amd.com>

[flang][OpenMP] Parsing support for iterator modifiers in FROM and TO (#114593)

Parse PRESENT modifier as well while we're at it (no MAPPER though). Add
semantic checks for these clauses in the TAR

[flang][OpenMP] Parsing support for iterator modifiers in FROM and TO (#114593)

Parse PRESENT modifier as well while we're at it (no MAPPER though). Add
semantic checks for these clauses in the TARGET UPDATE construct, TODO
messages in lowering.

show more ...


# c478aab6 30-Oct-2024 Krzysztof Parzyszek <Krzysztof.Parzyszek@amd.com>

[flang][OpenMP] Parser support for DEPOBJ plus DEPEND, DESTROY, UPDATE (#114074)

Parse the DEPOBJ construct and the associated clauses, perform basic
semantic checks.


# d48c849e 29-Oct-2024 Krzysztof Parzyszek <Krzysztof.Parzyszek@amd.com>

[flang][OpenMP] Parsing support for iterator in DEPEND clause (#113622)

Warn about use of iterators OpenMP versions that didn't have them
(support added in 5.0). Emit a TODO error in lowering.


Revision tags: llvmorg-19.1.3
# 09a4bcf1 28-Oct-2024 Krzysztof Parzyszek <Krzysztof.Parzyszek@amd.com>

[flang][OpenMP] Update handling of DEPEND clause (#113620)

Parse the locator list in OmpDependClause as an OmpObjectList (instead
of a list of Designators). When a common block appears in the locat

[flang][OpenMP] Update handling of DEPEND clause (#113620)

Parse the locator list in OmpDependClause as an OmpObjectList (instead
of a list of Designators). When a common block appears in the locator
list, show an informative message.
Implement resolving symbols in DependSinkVec in a dedicated visitor
instead of having a visitor for OmpDependClause.
Resolve unresolved names common blocks in OmpObjectList.

Minor changes to the code organization:
- rename OmpDependenceType to OmpTaskDependenceType (to follow 5.2
terminology),
- rename Depend::WithLocators to Depend::DepType,
- add comments with more detailed spec references to parse-tree.h.

---------

Co-authored-by: Kiran Chandramohan <kiran.chandramohan@arm.com>

show more ...


# 973fa983 23-Oct-2024 Krzysztof Parzyszek <Krzysztof.Parzyszek@amd.com>

[flang][OpenMP] Parse iterators, add to MAP clause, TODO for lowering (#113167)

Define `OmpIteratorSpecifier` and `OmpIteratorModifier` parser classes,
and add parsing for them. Those are reusable

[flang][OpenMP] Parse iterators, add to MAP clause, TODO for lowering (#113167)

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.

show more ...


Revision tags: llvmorg-19.1.2
# 697d65de 11-Oct-2024 Krzysztof Parzyszek <Krzysztof.Parzyszek@amd.com>

[flang][OpenMP] Parsing support for map type modifiers (#111860)

This commit adds parsing of type modifiers for the MAP clause: CLOSE,
OMPX_HOLD, and PRESENT. The support for ALWAYS has already exi

[flang][OpenMP] Parsing support for map type modifiers (#111860)

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.

show more ...


# 88478a89 07-Oct-2024 Sergio Afonso <safonsof@amd.com>

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


# c4204c0b 03-Oct-2024 jeanPerier <jperier@nvidia.com>

[flang] replace fir.complex usages with mlir complex (#110850)

Core patch of
https://discourse.llvm.org/t/rfc-flang-replace-usages-of-fir-complex-by-mlir-complex-type/82292.
After that, the last s

[flang] replace fir.complex usages with mlir complex (#110850)

Core patch of
https://discourse.llvm.org/t/rfc-flang-replace-usages-of-fir-complex-by-mlir-complex-type/82292.
After that, the last step is to remove fir.complex from FIR types.

show more ...


Revision tags: llvmorg-19.1.1, llvmorg-19.1.0
# b54be00a 16-Sep-2024 Sergio Afonso <safonsof@amd.com>

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


# 70ef5eb6 13-Sep-2024 harishch4 <harishcse44@gmail.com>

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


# 2f3d0619 11-Sep-2024 Sergio Afonso <safonsof@amd.com>

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


# 53b59022 10-Sep-2024 David Truby <david.truby@arm.com>

[flang][OpenMP] Implement copyin for pointers and allocatables. (#107425)

The copyin clause currently forbids pointer and allocatable variables,
which are allowed by the OpenMP 1.1 and 3.0 specific

[flang][OpenMP] Implement copyin for pointers and allocatables. (#107425)

The copyin clause currently forbids pointer and allocatable variables,
which are allowed by the OpenMP 1.1 and 3.0 specifications respectively.

show more ...


123