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, llvmorg-19.1.0-rc3 |
|
#
6f8ef5ad |
| 05-Aug-2024 |
Kazu Hirata <kazu@google.com> |
[flang] Construct SmallVector with ArrayRef (NFC) (#101901)
|
Revision tags: llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init |
|
#
77d8cfb3 |
| 17-Jun-2024 |
Alexander Shaposhnikov <6532716+alexander-shaposhnikov@users.noreply.github.com> |
[Flang] Switch to common::visit more call sites (#90018)
Switch to common::visit more call sites.
Test plan: ninja check-all
|
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6 |
|
#
1710c8cf |
| 08-May-2024 |
Slava Zakharin <szakharin@nvidia.com> |
[flang] Lowering changes for assigning dummy_scope to hlfir.declare. (#90989)
The lowering produces fir.dummy_scope operation if the current
function has dummy arguments. Each hlfir.declare generat
[flang] Lowering changes for assigning dummy_scope to hlfir.declare. (#90989)
The lowering produces fir.dummy_scope operation if the current
function has dummy arguments. Each hlfir.declare generated
for a dummy argument is then using the result of fir.dummy_scope
as its dummy_scope operand. This is only done for HLFIR.
I was not able to find a reliable way to identify dummy symbols
in `genDeclareSymbol`, so I added a set of registered dummy symbols
that is alive during the variables instantiation for the current
function. The set is initialized during the mapping of the dummy
argument symbols to their MLIR values. It is reset right after
all variables are instantiated - this is done to avoid generating
hlfir.declare operations with dummy_scope for the clones of
the dummy symbols (e.g. this happens with OpenMP privatization).
If this can be done in a cleaner way, please advise.
show more ...
|
Revision tags: llvmorg-18.1.5 |
|
#
fac349a1 |
| 28-Apr-2024 |
Christian Sigg <chsigg@users.noreply.github.com> |
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406)
…ted. (#89998)" (#90250)
This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087.
This change rem
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406)
…ted. (#89998)" (#90250)
This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087.
This change removes calls to the deprecated member functions. It does
not mark the functions deprecated yet and does not disable the
deprecation warning in TypeSwitch. This seems to cause problems with
MSVC.
show more ...
|
#
7aedd7dc |
| 26-Apr-2024 |
dyung <douglas.yung@sony.com> |
Revert "[mlir] Mark `isa/dyn_cast/cast/...` member functions deprecated. (#89998)" (#90250)
This reverts commit 950b7ce0b88318f9099e9a7c9817d224ebdc6337.
This change is causing build failures on
Revert "[mlir] Mark `isa/dyn_cast/cast/...` member functions deprecated. (#89998)" (#90250)
This reverts commit 950b7ce0b88318f9099e9a7c9817d224ebdc6337.
This change is causing build failures on a bot
https://lab.llvm.org/buildbot/#/builders/216/builds/38157
show more ...
|
#
950b7ce0 |
| 26-Apr-2024 |
Christian Sigg <chsigg@users.noreply.github.com> |
[mlir] Mark `isa/dyn_cast/cast/...` member functions deprecated. (#89998)
See https://mlir.llvm.org/deprecation and
https://discourse.llvm.org/t/preferred-casting-style-going-forward.
|
Revision tags: llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3 |
|
#
93fea7dd |
| 08-Aug-2023 |
Slava Zakharin <szakharin@nvidia.com> |
[flang][hlfir] Support mold operand for hlfir.elemental.
To properly create temporary array for a polymorphic result of hlfir.elemental we need to keep the mold as its operand. This patch adds just
[flang][hlfir] Support mold operand for hlfir.elemental.
To properly create temporary array for a polymorphic result of hlfir.elemental we need to keep the mold as its operand. This patch adds just the basic support.
Reviewed By: clementval, tblah
Differential Revision: https://reviews.llvm.org/D157315
show more ...
|
Revision tags: llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init |
|
#
b9e435cb |
| 19-Jul-2023 |
Slava Zakharin <szakharin@nvidia.com> |
[flang][hlfir] Removed incorrect clean-up in the implied-do lowering.
The lowering of calls/expressions unconditionally inserts DestroyOp clean-up for hlfir.expr values, which is wrong in the case w
[flang][hlfir] Removed incorrect clean-up in the implied-do lowering.
The lowering of calls/expressions unconditionally inserts DestroyOp clean-up for hlfir.expr values, which is wrong in the case where the value is used as a result of the elemental operation created during the implied-do lowering. A cleaner fix could be to avoid DestroyOp insertion at all, but I have not figure out an easy way to do it. The DestroyOp look-up I used seems to be quite reliable, so it should just work.
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D155665
show more ...
|
#
7b4aa95d |
| 29-Jun-2023 |
Slava Zakharin <szakharin@nvidia.com> |
[flang][hlfir] Set/propagate 'unordered' attribute for elementals.
This patch adds 'unordered' attribute handling the HLFIR elementals' builders and fixes the attribute handling in lowering and tran
[flang][hlfir] Set/propagate 'unordered' attribute for elementals.
This patch adds 'unordered' attribute handling the HLFIR elementals' builders and fixes the attribute handling in lowering and transformations.
Depends on D154031, D154032
Reviewed By: jeanPerier, tblah
Differential Revision: https://reviews.llvm.org/D154035
show more ...
|
Revision tags: llvmorg-16.0.6, llvmorg-16.0.5 |
|
#
9ac452b2 |
| 23-May-2023 |
Jean Perier <jperier@nvidia.com> |
[flang][NFC] Move Array constructor inlined temp management into a utility
This patch moves the counter and storage management part of the array constructor inlined temporary strategy into its own u
[flang][NFC] Move Array constructor inlined temp management into a utility
This patch moves the counter and storage management part of the array constructor inlined temporary strategy into its own utility so that it can be reused for the simple cases of temporary creations inside WHERE and FORALL.
It actually fixes a bug where the counter first value used for addressing was "2" leading to read/write after the allocated storage... It seems I ran the tests end-to-end without the HLFIR flag when previously testing this. So this may clear some segfaults.
Differential Revision: https://reviews.llvm.org/D151106
show more ...
|
Revision tags: llvmorg-16.0.4 |
|
#
ebae4cc7 |
| 05-May-2023 |
Slava Zakharin <szakharin@nvidia.com> |
[flang][hlfir] Fixed array constructor lowering.
First issue is that the clean-ups were generated after the yield_element operation that must be the terminator. Second issue is that codegen for elem
[flang][hlfir] Fixed array constructor lowering.
First issue is that the clean-ups were generated after the yield_element operation that must be the terminator. Second issue is that codegen for elemenal operation was not working properly with nested elemental ops.
Differential Revision: https://reviews.llvm.org/D149921
show more ...
|
Revision tags: llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4 |
|
#
bc991d94 |
| 24-Feb-2023 |
Jean Perier <jperier@nvidia.com> |
[flang][hlfir] Array constructor lowering [part 4/4]
Enable character and derived type array constructor lowering. Nothing special needs to be done other than lowering the types before the array con
[flang][hlfir] Array constructor lowering [part 4/4]
Enable character and derived type array constructor lowering. Nothing special needs to be done other than lowering the types before the array constructor lowering. Derived type are forced to use the runtime for now to avoid undesired usage of user defined assignment that hlfir.assign may trigger when using the runtime.
Differential Revision: https://reviews.llvm.org/D144548
show more ...
|
#
9683a9c9 |
| 24-Feb-2023 |
Jean Perier <jperier@nvidia.com> |
[flang][hlfir] Array constructor lowering [part 3/4]
Lower the cases that require runtime support to deal with the allocation, reallocation, or copy of ac-values to the array constructor storage.
D
[flang][hlfir] Array constructor lowering [part 3/4]
Lower the cases that require runtime support to deal with the allocation, reallocation, or copy of ac-values to the array constructor storage.
Differential Revision: https://reviews.llvm.org/D144513
show more ...
|
#
5226f8a9 |
| 22-Feb-2023 |
Jean Perier <jperier@nvidia.com> |
[flang][runtime] Add API to help with the difficult array constructor cases
This runtime API can be used to lower any flavor of array constructors, but is mainly intended to be used with:
- array c
[flang][runtime] Add API to help with the difficult array constructor cases
This runtime API can be used to lower any flavor of array constructors, but is mainly intended to be used with:
- array constructors for which the extent or length parameters cannot be computed without lowering some ac-value or ac-implied-do-control that cannot be pre-evaluated.
- array constructors of a derived type with allocatable component where copy is not trivial or PDTS.
Example of use cases: - `[((i+j,i=1, ifoo()), j=1,n)]` where ifoo() is not pure. - `[return_allocatable_array(), return_allocatable_array()]`
Differential Revision: https://reviews.llvm.org/D144411
show more ...
|
Revision tags: llvmorg-16.0.0-rc3 |
|
#
a9e4bb38 |
| 16-Feb-2023 |
Jean Perier <jperier@nvidia.com> |
[flang][hlfir] Array constructor lowering [part 2/4]
This patch adds the lowering strategy that lowers an array constructor to an hlfir.elemental (without creating any temporary yet in lowering). Th
[flang][hlfir] Array constructor lowering [part 2/4]
This patch adds the lowering strategy that lowers an array constructor to an hlfir.elemental (without creating any temporary yet in lowering). This will allow more high level array expression optimization to elide the array constructor temporary when possible, but this is only doable for a restricted although common form of array constructors: "[(pure_scalar_expr(i),i=lower,upper,stride)]".
Differential Revision: https://reviews.llvm.org/D144111
show more ...
|
#
ffde9f17 |
| 16-Feb-2023 |
Jean Perier <jperier@nvidia.com> |
[flang][hlfir] Array constructor lowering [part 1/4]
This is the first and biggest chunk that introduces support for array constructor to HLFIR.
This patch: - adds a new ConvertArrayConstructor.cpp
[flang][hlfir] Array constructor lowering [part 1/4]
This is the first and biggest chunk that introduces support for array constructor to HLFIR.
This patch: - adds a new ConvertArrayConstructor.cpp that centralizes the code dealing with array constructor lowering. - introduces a framework to lower array constructor according to different strategies: A common analysis of the array constructor is done, and based on that, a lowering startegy is selected and driven through the ac-values of the array constructor. See ConvertArrayConstructor.cpp comments for more details. - implements the first strategy that creates a temporary inlined and updates it with inlined code. This strategy can only be used if the temporary can be pre-allocated (i.e: the extents and length parameters can be pre-computed without evaluating any ac-values), and if all the ac-value expressions are scalars.
For the sake of simplicity, characters and derived type will be enabled once all the strategies are added.
Reviewed By: clementval, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D144102
show more ...
|