|
Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5 |
|
| #
2918a47f |
| 28-Nov-2024 |
Kareem Ergawy <kareem.ergawy@amd.com> |
[mlir][OpenMP] Annotate `private` vars with `map_idx` when needed (#116770)
This PR extends the MLIR representation for `omp.target` ops by adding a
`map_idx` to `private` vars. This annotation sto
[mlir][OpenMP] Annotate `private` vars with `map_idx` when needed (#116770)
This PR extends the MLIR representation for `omp.target` ops by adding a
`map_idx` to `private` vars. This annotation stores the index of the map
info operand corresponding to the private var. If the variable does not
have a map operand, the `map_idx` attribute is either not present at all
or its value is `-1`.
This makes matching the private variable to its map info op easier (see
https://github.com/llvm/llvm-project/pull/116576 for usage).
show more ...
|
|
Revision tags: llvmorg-19.1.4, llvmorg-19.1.3 |
|
| #
11dad2fa |
| 20-Oct-2024 |
Pranav Bhandarkar <pranav.bhandarkar@amd.com> |
[flang][OpenMP] - Add `MapInfoOp` instances for target private variables when needed (#109862)
This PR adds an OpenMP dialect related pass for FIR/HLFIR which creates
`MapInfoOp` instances for cert
[flang][OpenMP] - Add `MapInfoOp` instances for target private variables when needed (#109862)
This PR adds an OpenMP dialect related pass for FIR/HLFIR which creates
`MapInfoOp` instances for certain privatized symbols. For example, if an
allocatable variable is used in a private clause attached to a
`omp.target` op, then the allocatable variable's descriptor will be
needed on the device (e.g. GPU). This descriptor needs to be separately
mapped onto the device. This pass creates the necessary `omp.map.info`
ops for this.
show more ...
|
|
Revision tags: llvmorg-19.1.2 |
|
| #
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 ...
|
| #
cdb3ebf1 |
| 01-Oct-2024 |
Sergio Afonso <safonsof@amd.com> |
[MLIR][OpenMP] Normalize representation of entry block arg-defining clauses (#109809)
This patch updates printing and parsing of operations including clauses
that define entry block arguments to th
[MLIR][OpenMP] Normalize representation of entry block arg-defining clauses (#109809)
This patch updates printing and parsing of operations including clauses
that define entry block arguments to the operation's region. This
impacts `in_reduction`, `map`, `private`, `reduction` and
`task_reduction`.
The proposed representation to be used by all such clauses is the
following:
```
<clause_name>([byref] [@<sym>] %value -> %block_arg [, ...] : <type>[, ...]) {
...
}
```
The `byref` tag is only allowed for reduction-like clauses and the
`@<sym>` is required and only allowed for the `private` and
reduction-like clauses. The `map` clause does not accept any of these
two.
This change fixes some currently broken op representations, like
`omp.teams` or `omp.sections` reduction:
```
omp.teams reduction([byref] @<sym> -> %value : <type>) {
^bb0(%block_arg : <type>):
...
}
```
Additionally, it addresses some redundancy in the representation of the
previously mentioned cases, as well as e.g. `map` in `omp.target`. The
problem is that the block argument name after the arrow is not checked
in any way, which makes some misleading representations legal:
```mlir
omp.target map_entries(%x -> %arg1, %y -> %arg0, %z -> %doesnt_exist : !llvm.ptr, !llvm.ptr, !llvm.ptr) {
^bb0(%arg0 : !llvm.ptr, %arg1 : !llvm.ptr, %arg2 : !llvm.ptr):
...
}
```
In that case, `%x` maps to `%arg0`, contrary to what the representation
states, and `%z` maps to `%arg2`. `%doesnt_exist` is not resolved, so it
would likely cause issues if used anywhere inside of the operation's
region.
The solution implemented in this patch makes it so that values
introduced after the arrow on the representation of these clauses
implicitly define the corresponding entry block arguments, removing the
potential for these problematic representations. This is what is already
implemented for the `private` and `reduction` clauses of `omp.parallel`.
There are a couple of consequences of this change:
- Entry block argument-defining clauses must come at the end of the
operation's representation and in alphabetical order. This is because
they are printed/parsed as part of the region and a standardized
ordering is needed to reliably match op arguments with their
corresponding entry block arguments via the `BlockArgOpenMPOpInterface`.
- We can no longer define per-clause assembly formats to be reused by
all operations that take these clauses, since they must be passed to a
custom printer including the region and arguments of all other entry
block argument-defining clauses. Code duplication and potential for
introducing issues is minimized by providing the generic
`{print,parse}BlockArgRegion` helpers and associated structures.
MLIR and Flang lowering unit tests are updated due to changes in the
order and formatting of impacted operations.
show more ...
|
|
Revision tags: llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8 |
|
| #
1539da46 |
| 07-Jun-2024 |
Kareem Ergawy <kareem.ergawy@amd.com> |
[flang][OpenMP] Add `--openmp-enable-delayed-privatization-staging` flag (#94749)
|
| #
913a8244 |
| 07-Jun-2024 |
Kareem Ergawy <kareem.ergawy@amd.com> |
[flang][OpenMP] Lower `target .. private(..)` to `omp.private` ops (#94195)
Extends delayed privatization support to `taraget .. private(..)`. With
this PR, `private` is support for `target` **only
[flang][OpenMP] Lower `target .. private(..)` to `omp.private` ops (#94195)
Extends delayed privatization support to `taraget .. private(..)`. With
this PR, `private` is support for `target` **only** is delayed
privatization mode.
show more ...
|