[flang][openacc] Representing Fortran descriptor management with OpenACC.

[vzakhari]

This document describes the aspects of Fortran descriptor management
in the offload data environment and how this semantics can be represented
using MLIR OpenACC dialect.

In the document I tried to clarify some parts of the OpenACC specification
that seemed unclear to me, e.g. where the spec allowed different
interpretations (in my opinion) or did not specify the actual runtime
behavior. I tried to demonstrate how this ambiguity can affect user
programs with examples.

The document proposes using attachRecipe on the data operations
to represent the non-trivial pointer attachment semantics for variables
represented by descriptors. The recipe provides the actual implementation
of the pointer attachment, e.g. we can call an F18 offload runtime
function that will perform all necessary checks and actions.

It is unclear at this point if we want to expose the implementation
details in FIR, otherwise, the recipe could have contained more low level
acc operations such as is_present lookups, host to device memory copies, etc.

[clementval]

Thanks for the document Slava! I think not exposing the implementation details of the descriptor in the FIR dialect is also good to respect the fir.box design. It is supposed to be an abstraction of the a descriptor and not necessarily the f18 cfi descriptor as implemented in the runtime.

[agozillon]

Thank you very much for this!

I quite like this proposal and I believe we'd like to go down this direction in the future, however, I think for the moment we'd like to continue down the current direction of the existing PR for adding some initial support if it's feasible and see the mileage we can get out of it in the meantime (if any, after the changes requested in the PR), so we can at least have some support for descriptor related types currently. We'd then transition to this proposal at a later date and I'd be happy to do the transition myself when the infrastructure is there.

I'm currently trying to find out a bit more about the details on how similar the implicit descriptor mapping in OpenMP would be to those described for OpenACC in this proposal, I've emailed someone far more knowledgeable than myself on it, they're a little busy at the moment however, so it might take a while to get OpenMP's behavior on this clarified further. However, even if the way descriptors are handled in OpenMP is less complex (I'm personally doubtful it will be too different in the cases that are applicable to OpenMP, but I could be quite wrong), I think we'd still be happy to adopt this approach as it gives a lot more flexibility and future proofing against OpenMP and Fortran specification (and implementation) changes to descriptor and their mapping requirements.

[razvanlupusoru]

Slava, this is outstanding. Thank you for your thorough documentation explaining the challenges, the many nuanced examples, and the recommended solution. The recommended representation looks great to me.

[vzakhari]

Thank you all for the reviews!

@agozillon, I consider this OpenACC specific for the time being. It will be great to find some commonalities with OpenMP, but this proposal is not intended to block your efforts to support the descriptors mapping in any way. Thanks!

[agozillon]

Thank you @vzakhari I didn't think it was intended to block just educate, which I appreciate greatly (sorry if my previous comment came across weirdly in some way)! I mainly wanted to show interest in this method, I think it's a good way to deal with it in general and think it'd be good to align OpenMP with this method in the long-term if possible. I am also interested in finding the commonalities and differences between OpenMP and OpenACC in regards to this type of mapping, if anything just to clarify how things are intended to work for myself in the case of more complex interactions!