[flang-commits] [flang] [llvm] [mlir] [Flang][MLIR][OpenMP] Allow setting OMP_MAP_PTR_AND_OBJ by frontends (PR #84328)

[Slava Zakharin via flang-commits]

vzakhari wrote:

> While varPtrPtr makes sense for use with descriptors, I am not sure it makes sense for declare target, where the type at a FIR/LLVM dialect level has nothing to do with a pointer/pointee coupling, more to do with the end state of declare target. So, I am not so sure correlating the two things is ideal, there may be cases where the map flag is necessary (i.e. declare target) but varPtrPtr isn't and vice versa.

I see.  I guess it would not make sense for the declare targets.  Thanks for the explanation!

> The tracing back was required, as when you are mapping a structure and member pointer pairing (or presumably any member of a structure) the address of the member needs to be part of the originating structure (or in it's address range) to be correctly attached by the runtime (at least that's how I understood the issue at the time, perhaps I misinterpreted it). So, the dislocation of the two mappings (member and parent) to seperate allocations was not ideal. However, this is not the case when using BoxAddrOf.

I might be wrong, but I think all the information for invoking libomptarget should be available in `varPtr` and `varPtrPtr`, i.e. the corresponding `Args` pointer is the value of in `varPtr` (which is the value of the data pointer potentially offset'ed due to array section), and the `ArgBases` pointer is the value in `varPtrPtr` (which is the address of the member within the data structure, be it a descriptor or a C structure).

Okay, I guess I missed my chance to get more details, since there have been a lot of rework, as you said :)

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