History log of /llvm-project/flang/lib/Lower/OpenMP/ReductionProcessor.cpp (Results 26 – 30 of 30)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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 ...


Revision tags: llvmorg-18.1.2
# 63e70c05 15-Mar-2024 Krzysztof Parzyszek <Krzysztof.Parzyszek@amd.com>

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


# f46f5a01 13-Mar-2024 Tom Eccles <tom.eccles@arm.com>

[flang][OpenMP][OMPIRBuilder][mlir] Optionally pass reduction vars by ref (#84304)

Previously reduction variables were always passed by value into and out
of the initialization and combiner regions

[flang][OpenMP][OMPIRBuilder][mlir] Optionally pass reduction vars by ref (#84304)

Previously reduction variables were always passed by value into and out
of the initialization and combiner regions of the OpenMP reduction
declare operation.

This worked well for reductions of primitive types (and might perform
better than passing by reference). But passing by reference will be
useful for array and derived type reductions (e.g. to move allocation
inside of the init region).

Passing reductions by reference requires different LLVM-IR generation
when lowering from MLIR because some of the loads/stores/allocations
will now be moved inside of the init and combiner regions. This
alternate code generation is requested using a new attribute to
omp.wsloop and omp.parallel.

Existing lowerings from mlir are unaffected (these will continue to use
the by-value argument passing.

Flang will continue to pass by-value argument passing for trivial types
unless a (hidden) command line argument is supplied. Non-trivial types
will always use the by-ref lowering.

Array reductions are not ready yet (but are coming very soon). In the
meantime, this is tested by forcing existing reductions to use by-ref.

Commit series for by-ref OpenMP reductions 3/3

---------

Co-authored-by: Mats Petersson <mats.petersson@arm.com>

show more ...


Revision tags: llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4
# 4d4af15c 21-Feb-2024 Kareem Ergawy <kareem.ergawy@amd.com>

[NFC][flang][OpenMP] Split `DataSharing` and `Clause` processors (#81973)

This started as an experiment to reduce the compilation time of
iterating over `Lower/OpenMP.cpp` a bit since it is too slo

[NFC][flang][OpenMP] Split `DataSharing` and `Clause` processors (#81973)

This started as an experiment to reduce the compilation time of
iterating over `Lower/OpenMP.cpp` a bit since it is too slow at the
moment. Trying to do that, I split the `DataSharingProcessor`,
`ReductionProcessor`, and `ClauseProcessor` into their own files and
extracted some shared code into a util file. All of these new `.h/.cpp`
files as well as `OpenMP.cpp` are now under a `Lower/OpenMP/` directory.

This resulted is a slightly better organization of the OpenMP lowering
code and hence opening this NFC.

As for the compilation time, this unfortunately does not affect it much
(it shaves off a few seconds of `OpenMP.cpp` compilation) since from
what I learned the bottleneck is in `DirectivesCommon.h` and
`PFTBuilder.h` which both consume a lot of time in template
instantiation it seems.

show more ...


12