[RFC] Updating/extending the OpenMP dialects map to support array boundaries, capture type and a refactoring

Currently I have a series of Phabricator patches open that seek to build on the existing work done for OpenMP’s map clauses, the patches aim to extend the stored map information via:

• Boundary information for an argument (a new DataBoundsOp), the boundary information can be used for array sectioning.
• A “Capture Type” which indicates if the map variable should be captured ByVal, ByRef, This and VLAType (in the form of an enum attribute), this is to aid in lowering the dialect to LLVM-IR, this is OpenMP information Clang stores currently and uses to alter its code generation for mapped variables.

The patch series also collates up the map information into a new operation named MapEntryOp, which OpenMP operations that contain map clauses store a list of, helping to abstract away the map related information from the specific data handling target operation. So for example, TargetOp has a list of MapEntryOp which can contain a DataBoundsOp.

This patch series borrows a lot from OpenACC’s current implementation of bounds (also named DataBoundsOp), and DataEntryOps (which OpenMP will rename MapEntryOp for some specification consistency), so a big thank you to the OpenACC developers. There is some differentiation, such as OpenMP specific information, but the main difference is that OpenMP data related operations contain MapEntryOps whereas OpenACC’s data related operations derive from there equivalent DataEntryOp. I have chosen to not derive for the moment to keep some consistency with how Map clauses are currently handled in OpenMP to make the transition simpler.

The Phabricator patch series can be found here for lowering from Fortran to the new MLIR operation:

However, the dialect changes are within this patch: ⚙ D158732 [OpenMP][MLIR] Refactor and extend current map support by adding MapEntry and Bounds operations to the OpenMP Dialect

I was wondering if anyone is opposed to these map changes or has any comments/input on this direction? And please do feel free to add comments to the Phabricator patches as well if you go over them and spot anything.

As a possible ancillary aside I have had some success in using these new map extensions to lower from Fortran+OpenMP to LLVM-IR that can be further lowered for offloading to GPU in a downstream patch (happy to give the link if there is some interest in it, but I hope to upstream it in time and progress it further). It currently handles some basic cases for Fortran simple data types, 1-D arrays (with basic sectioning) and derived types (C++ class equivalent) of simple data types, but still a long way to go I think, e.g. 2-D+ arrays, pointers and allocatables, and structure sectioning(probably not the correct terminology).

2 Likes