[flang-commits] [openmp] [flang] [mlir] [Flang][OpenMP] Initial mapping of Fortran pointers and allocatables for target devices (PR #71766)

[via flang-commits]

agozillon wrote:

> Please note that, moving forward, we will have to "attach" more pointers into the device descriptor, e.g. the `addendum` pointer may point to the type description data. To preserve the correctness of a descriptor on the device something like `map(to: descriptor->addendum)` will have to be used. It might as well be `map(present: descriptor->addendum)`, if the type description data is implicitly made `declare target` (i.e. it is always resident in the device memory as global data).

That's unfortunate in some ways (but understandable) as it'd possibly be quite changeable over time. Yes, I think most pointers components of the descriptor that are required will have to be mapped over like this unfortunately (perhap there's a way around it though). This patch is primarily focusing on  just the regular map at the moment, I imagine declare target will come with it's own host of issues unfortunately (but I will keep this in mind for future!).

> So I think we have to plan for a representation that will be able to handle the `addendum` and maybe other auxiliary pointers inside the descriptor.

Well, on the plus side, doing it the current way makes it quite easy to specialize for these kind of changes, at the cost of losing frontend agnosticism.

On the other hand if we can treat it as a derived type that the Frontend can generate implicit map clauses for that would also work if it is possible to create accessors to individual descriptor members that are pointers, so generating clauses like the below when encountering a descriptor e.g. :

map(to: descriptor->addendum)
map(to: descriptor->data)

If it's not possible to do the above on initial creation of the original map, it might be possible to generate them during rewrite or in a later pass. For the moment it's at least possible to do the following on initial map:

map(to: descriptor)
map(to: descriptor->data)

However, I'm open to new representations for this kind of mapping, I'm just not sure what that'd be at the moment (new OpenMP/OpenACC dialect operation, something in FIR?), do you or anyone else have any thoughts on it?

> I suppose the MapInfo can be extended to represent the parent-memberptr relationship, so that a "root" MapInfo for the descriptor reference refers to a chain of MapInfo's for the descriptor member pointers. It should be pretty straightforward to convert this to the corresponding `MEMBER_OF|PTR_AND_OBJ` mappings for libomptarget. The same representation can be used then for C/C++ like `map(to:s.p1[:10],s.p2[:20],s.p3[:30])` (whenever omp dialect is used for C/C++).

Yes, I had something similar yet not as elaborate previously using varPtrPtr incorrectly, I think there was some minor things that needed to be ironed out before I moved over to this direction, but I could likely look back into the previous direction utilising a parent <-> member mapping mechanism for map_infos if this is a representation we believe is acceptable?  

> Side note: I am having problems finding commonalities between OpenMP and OpenACC with regards to the pointer attachments, because OpenACC spec explicitly describes a complex logic for updating the pointer attachment counters (which, for example, involves comparing the current value of the descriptor with the value that has been used for attachment the last time). So I am not sure if we can come up with a representation that will be close for OpenMP and OpenACC.

I'm unfortunately not an OpenMP guru (in-fact rather beginner unfortunately), we do have @mjklemm on the team (who is an OpenMP expert) that can very likely answer any questions you might have in this case. However, I do think the OpenMP specifications current iterations are very lax with descriptor mapping details from what I've found and are left up in large to the implementer, I think some more details are forth coming in future iterations, but I am not sure they're quite as detailed as explaining how the updating occurs. 

Having a representation that can be shared would be ideal, perhaps difficult but it might still be possible, at least from the perspective of access to the relevant information for lowering. OpenACC might just utilise more of the available information than OpenMP does currently. I could be incorrect however, I'm not at all familiar with OpenACC's needs in this case!

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