This set of commits resolves some of the issues with elemental calls producing
results that may require finalization, and also some memory leak issues due to
the missing deallocation of allocatable components of the temporary buffers
created by the bufferization pass.
- [flang][runtime] Expose Finalize API for derived types.
- [flang][hlfir] Add 'finalize' attribute for DestroyOp.
- [flang][hlfir] Postpone result finalization for elemental calls.
The results of elemental calls generated inside hlfir.elemental must not
be finalized/destructed before they are copied into the resulting
array. The finalization must be done on the array as a whole
(e.g. there might be different scalar and array finalization routines).
The finalization work is left to the hlfir.destroy corresponding
to this hlfir.elemental.
- [flang][hlfir] Tighten requirements on hlfir.end_associate operand.
If component deallocation might be required for the operand of
hlfir.end_associate, we have to be able to get the variable
shape/params to create a descriptor for calling the runtime.
This commit adds verification that we can do so.
- [flang][hlfir] Lower argument clean-ups using valid hlfir.end_associate.
The operand must be a Fortran entity, when allocatable component
deallocation may be required.
- [flang][hlfir] Properly clean-up temporary buffers in bufferization pass.
This commit combines changes for proper finalization and component
deallocation of the temporary buffers. The finalization part
relates to hlfir.destroy operations with 'finalize' attribute.
The component deallocation might be invoked for both hlfir.destroy
and hlfir.end_associate, if the operand is of a derived type
with allocatable component(s).
The changes are mostly in one function, so I decided not to split them.
- [flang][hlfir] Disable optimizations for hlfir.elemental requiring finalization.
If hlfir.elemental is coupled with hlfir.destroy with 'finalize' attribute,
the temporary array result of hlfir.elemental needs to be created
for the purpose of finalization. We cannot do certain optimizations
on such hlfir.elemental operations.
I was not able to come up with a test for the OptimizedBufferization pass,
but I put the check there as well.
hlfir.count lowering was using incorrect default integer kind
by ignoring the kind specified in the ModuleOp.
Reviewed By: tblah
Differential Revision: https://reviews.llvm.org/D156017
This patch just disables inlining of ordered hlfir.elemental operations.
Proving the safeness of inlining is left for future development.
Depends on D154032
Reviewed By: jeanPerier, tblah
Differential Revision: https://reviews.llvm.org/D154034
InlineElementals created a regression when inlining elemental
expressions where the type of the result of the hlfir.apply does not
match the hlfir.yield.
This patch ensures the pass doesn't match in these cases, fixing the
regression.
It isn't clear to me what the /right/ solution is:
- Is it actually valid for the hlfir.apply to have a different type
(even just different array bounds?). Should this be enforced in the
verifier?
- Inserting a convert if these types don't match doesn't work because
fir.convert doesn't know how to convert a hlfir.expr. Should this be
added?
Test case is from @vzakhari
Differential Revision: https://reviews.llvm.org/D151202
Implement hlfir.elemental inlining as proposed in
flang/docs/HighLevelFIR.md.
This is a separate pass to make the code easier to understand. One
alternative would have been to modify the hlfir.elemental lowering in
the HLFIR bufferization pass.
Currently, a hlfir.elemental can only be inlined once; if there are
more uses, the existing bufferization is used instead.
Usage of mlir::applyPatternsAndFoldGreedily was suggested by @jeanPerier
Differential Revision: https://reviews.llvm.org/D149258
