History log of /llvm-project/flang/lib/Lower/ConvertArrayConstructor.cpp (Results 1 – 16 of 16)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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 ...