|
Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4 |
|
| #
f2027a93 |
| 22-Aug-2024 |
Tom Eccles <tom.eccles@arm.com> |
[flang][OpenMP] use reduction alloc region (#102525)
I removed the `*-hlfir*` tests because they are duplicate now that the
other tests have been updated to use the HLFIR lowering.
3/3
Part 1:
[flang][OpenMP] use reduction alloc region (#102525)
I removed the `*-hlfir*` tests because they are duplicate now that the
other tests have been updated to use the HLFIR lowering.
3/3
Part 1: https://github.com/llvm/llvm-project/pull/102522
Part 2: https://github.com/llvm/llvm-project/pull/102524
show more ...
|
|
Revision tags: llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6 |
|
| #
74a87548 |
| 16-May-2024 |
Tom Eccles <tom.eccles@arm.com> |
[flang][MLIR][OpenMP] make reduction by-ref toggled per variable (#92244)
Fixes #88935
Toggling reduction by-ref broke when multiple reduction clauses were
used. Decisions made for the by-ref st
[flang][MLIR][OpenMP] make reduction by-ref toggled per variable (#92244)
Fixes #88935
Toggling reduction by-ref broke when multiple reduction clauses were
used. Decisions made for the by-ref status for later clauses could then
invalidate decisions for earlier clauses. For example,
```
reduction(+:scalar,scalar2) reduction(+:array)
```
The first clause would choose by value reduction and generate by-value
reduction regions, but then after this the second clause would force
by-ref to support the array argument. But by the time the second clause
is processed, the first clause has already had the wrong kind of
reduction regions generated.
This is solved by toggling whether a variable should be reduced by
reference per variable. In the above example, this allows only `array`
to be reduced by ref.
show more ...
|
|
Revision tags: llvmorg-18.1.5 |
|
| #
18bf0c3c |
| 24-Apr-2024 |
Tom Eccles <tom.eccles@arm.com> |
[flang][OpenMP] fix reduction of arrays with non-default lower bounds (#89611)
It turned out that `hlfir::genVariableBox` didn't add lower bounds to
the boxes it created. Using a shapeshift instead
[flang][OpenMP] fix reduction of arrays with non-default lower bounds (#89611)
It turned out that `hlfir::genVariableBox` didn't add lower bounds to
the boxes it created. Using a shapeshift instead of only a shape adds
the lower bounds information to the thread-local copy of the box.
Fixes #89259
show more ...
|
| #
8cc34fad |
| 23-Apr-2024 |
Tom Eccles <tom.eccles@arm.com> |
[flang][OpenMP] Support reduction of allocatable variables (#88392)
Both arrays and trivial scalars are supported. Both cases must use
by-ref reductions because both are boxed.
My understanding
[flang][OpenMP] Support reduction of allocatable variables (#88392)
Both arrays and trivial scalars are supported. Both cases must use
by-ref reductions because both are boxed.
My understanding of the standards are that OpenMP says that this should
follow the rules of the intrinsic reduction operators in fortran, and
fortran says that unallocated allocatable variables can only be
referenced to allocate them or test if they are already allocated.
Therefore we do not need a null pointer check in the combiner region.
show more ...
|
|
Revision tags: llvmorg-18.1.4 |
|
| #
6f068b9c |
| 11-Apr-2024 |
Tom Eccles <tom.eccles@arm.com> |
[flang][OpenMP] Allocate array reduction variables on the heap (#87773)
Following up on a review comment:
https://github.com/llvm/llvm-project/pull/84958#discussion_r1527627848
Reductions might
[flang][OpenMP] Allocate array reduction variables on the heap (#87773)
Following up on a review comment:
https://github.com/llvm/llvm-project/pull/84958#discussion_r1527627848
Reductions might be inlined inside of a loop so stack allocations are
not safe.
Normally flang allocates arrays on the stack. Allocatable arrays have a
different type: fir.box<fir.heap<fir.array<...>>> instead of
fir.box<fir.array<...>>. This patch will allocate all arrays on the
heap.
Reductions on allocatable arrays still aren't supported (but I will get
to this soon).
show more ...
|
| #
698bf3da |
| 04-Apr-2024 |
Sourabh Singh Tomar <sourabhsingh.tomar@amd.com> |
[flang][OpenMP] Fix for #86393 (#87452)
|
|
Revision tags: llvmorg-18.1.3 |
|
| #
3deaa77f |
| 20-Mar-2024 |
Tom Eccles <tom.eccles@arm.com> |
[flang][OpenMP] simplify getReductionName (#85666)
Re-use fir::getTypeAsString instead of creating something new here. This
spells integer names like i32 instead of i_32 so there is a lot of test
[flang][OpenMP] simplify getReductionName (#85666)
Re-use fir::getTypeAsString instead of creating something new here. This
spells integer names like i32 instead of i_32 so there is a lot of test
churn.
show more ...
|
| #
d84252e0 |
| 20-Mar-2024 |
Sergio Afonso <safonsof@amd.com> |
[MLIR][OpenMP] NFC: Uniformize OpenMP ops names (#85393)
This patch proposes the renaming of certain OpenMP dialect operations with the
goal of improving readability and following a uniform naming
[MLIR][OpenMP] NFC: Uniformize OpenMP ops names (#85393)
This patch proposes the renaming of certain OpenMP dialect operations with the
goal of improving readability and following a uniform naming convention for
MLIR operations and associated classes. In particular, the following operations
are renamed:
- `omp.map_info` -> `omp.map.info`
- `omp.target_update_data` -> `omp.target_update`
- `omp.ordered_region` -> `omp.ordered.region`
- `omp.cancellationpoint` -> `omp.cancellation_point`
- `omp.bounds` -> `omp.map.bounds`
- `omp.reduction.declare` -> `omp.declare_reduction`
Also, the following MLIR operation classes have been renamed:
- `omp::TaskLoopOp` -> `omp::TaskloopOp`
- `omp::TaskGroupOp` -> `omp::TaskgroupOp`
- `omp::DataBoundsOp` -> `omp::MapBoundsOp`
- `omp::DataOp` -> `omp::TargetDataOp`
- `omp::EnterDataOp` -> `omp::TargetEnterDataOp`
- `omp::ExitDataOp` -> `omp::TargetExitDataOp`
- `omp::UpdateDataOp` -> `omp::TargetUpdateOp`
- `omp::ReductionDeclareOp` -> `omp::DeclareReductionOp`
- `omp::WsLoopOp` -> `omp::WsloopOp`
show more ...
|
| #
197f3ecf |
| 20-Mar-2024 |
Tom Eccles <tom.eccles@arm.com> |
[flang][OpenMP] lower simple array reductions (#84958)
This has been tested with arrays with compile-time constant bounds.
Allocatable arrays and arrays with non-constant bounds are not yet
suppor
[flang][OpenMP] lower simple array reductions (#84958)
This has been tested with arrays with compile-time constant bounds.
Allocatable arrays and arrays with non-constant bounds are not yet
supported. User-defined reduction functions are also not yet supported.
The design is intended to work for arrays with non-constant bounds too
without a lot of extra work (mostly there are bugs in OpenMPIRBuilder I
haven't fixed yet).
We need some way to get these runtime bounds into the reduction init and
combiner regions. To keep things simple for now I opted to always box
the array arguments so the box can be passed as one argument and the
lower bounds and extents read from the box. This has the disadvantage of
resulting in fir.box_dim operations inside of the critical section. If
these prove to be a performance issue, we could follow OpenACC reading
box lower bounds and extents before the reduction and passing them as
block arguments to the reduction init and combiner regions. I would
prefer to keep things simple for now.
Note: this implementation only works when the HLFIR lowering is used. I
don't think it is worth supporting FIR-only lowering because the plan is
for that to be removed soon.
OpenMP array reductions 6/6
Previous PR: https://github.com/llvm/llvm-project/pull/84957
show more ...
|