[flang-commits] [flang] [flang][MLIR][OpenMP] Extend delayed privatization for arrays (PR #85023)
via flang-commits
flang-commits at lists.llvm.org
Tue Apr 23 01:34:04 PDT 2024
jeanPerier wrote:
> For me (and take this with a grain of salt since I didn't work on this part of the code base before) this seems like a bug in how hlfir.declare is generated: I think we should box the value regardless of whether it has the default or a non-default lower bound specified for the array.
@jeanPerier I think you will have a more informed input here. Can you please take a look and let me know what you think?
This is done on purpose: fir.box are used only if we need to because, without further knowledge, fir.box will increase the complexity of the codegen of operations that manipulate them (e.g., without access to defining op, contiguity information is lost statically, lower bounds must be fetched and increase complexity of addressing....). The approach of HLFIR is that the "entity" is the minimal SSA value that can fully represent the Fortran variable (base address, bounds, strides, length parameters if needed). For character, if the length is statically know, the hlfir::Entity will be a `fir.ref<fir.char<cst>>` while it is a fir.boxchar<> otehrwise.
In the case of `dimension(5) :: array`, we can retrieve from `!fir.ref<!fir.array<5xf32>>` the fact that the lower bounds are default and the upper bounds are in the type, so there is no need to use a more heavy weight SSA value type where the lower bounds are dynamically encoded.
All these differences should not impact the way one manipulate hlfir::Entity provided they use the hlfir tools to retrieve the base address/bounds/length.
https://github.com/llvm/llvm-project/pull/85023
More information about the flang-commits
mailing list