[flang-commits] [flang] [llvm] [mlir] [Flang][OpenMP] Remove target implicit allocatable member mapping from MapInfoFinalization and extend lowering to support it (PR #219434)

[via flang-commits]

agozillon wrote:

So, the scope of this PR actually had to change a bit to cover that case and another case that broke in check-offload after making the adjustments for that one.

But it boils down to having to allow the lowering to handle implicit mapping of allocatable derived types that contain allocatables, which is something I was aiming to do in any case as it's specification required, but this popping up just prompted it being a good time to do so. This required some alterations to the implicit declare mapper generation and some minor alterations to OpenMPToLLVMIRTranslation. 

The former is simplifying the mapping to only emit a map for the record type and the allocatable data (not the descriptor), as realistically mapping the whole record type and the data should map every non-allocatable part of the record (scalars, arrays, descriptors etc.) and mapping the data for an allocatable and it's relevant attach should correctly attach the data to the descriptor in the record even if it's mapped as an entire chunk (and if the allocatable happens to be some kind of record itself, we're mapping its entirety as well anyway, so it should handles itself). The one thing this approach won't handle is fragmenting the map type of members, i.e. x.x, x.y will always have the same map type as x, which in all implicit cases shouldn't matter as the overarching map type comes from the implicit mapping rules, which devolves to tofrom for record types.

The latter is simply preserving more map types from parents in the member mapping as we're no longer mapping constituent scalar components and the parents map bits are now important as they're not getting overwritten by the children. 

This will mainly result in simpler (and hopefully more performant) implicit mappings where we are not emitting as many maps to map the same amount of data, and it helps prevent cases where we have an enter/exit/update that's been sliced to optimally transfer data confusing later mappings by making sure the underlying starting point of the parent address remains consistent (ergo making sure the runtime can associate the maps correctly with each other). It will also allow more than a single layer of an allocatable derived type to have it's allocatable bits mapped, as the MapInfoFinalizaiton handling just handles a single layer.

https://github.com/llvm/llvm-project/pull/219434