| Age | Commit message (Collapse) | Author |
|---|
|
When inside a WHERE construct, the array constructor should be generated
within an hlfir.exactly_once region.
Fixes #130532
|
|
As described in
https://discourse.llvm.org/t/rfc-flang-representation-for-objects-inside-physical-storage/88026,
`[hl]fir.declare` should carry information about the layout
of COMMON/EQUIVALENCE variables within the physical storage.
This patch modifes Flang lowering to attach this information.
|
|
See #147168
|
|
See https://github.com/llvm/llvm-project/pull/147168 for more info.
|
|
|
|
Switch to common::visit more call sites.
Test plan: ninja check-all
|
|
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.
|
|
(#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.
|
|
(#89998)" (#90250)
This reverts commit 950b7ce0b88318f9099e9a7c9817d224ebdc6337.
This change is causing build failures on a bot
https://lab.llvm.org/buildbot/#/builders/216/builds/38157
|
|
See https://mlir.llvm.org/deprecation and
https://discourse.llvm.org/t/preferred-casting-style-going-forward.
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
