[llvm-branch-commits] [flang] [Flang][OpenMP][MLIR] Initial derived type member map support (PR #82853)

Sergio Afonso via llvm-branch-commits llvm-branch-commits at lists.llvm.org
Tue Apr 23 05:50:22 PDT 2024


================
@@ -903,24 +908,39 @@ bool ClauseProcessor::processMap(
           // Explicit map captures are captured ByRef by default,
           // optimisation passes may alter this to ByCopy or other capture
           // types to optimise
-          mlir::Value mapOp = createMapInfoOp(
+          mlir::omp::MapInfoOp mapOp = createMapInfoOp(
               firOpBuilder, clauseLocation, symAddr, mlir::Value{},
-              asFortran.str(), bounds, {},
+              asFortran.str(), bounds, {}, mlir::DenseIntElementsAttr{},
               static_cast<
                   std::underlying_type_t<llvm::omp::OpenMPOffloadMappingFlags>>(
                   mapTypeBits),
               mlir::omp::VariableCaptureKind::ByRef, symAddr.getType());
 
-          result.mapVars.push_back(mapOp);
-
-          if (mapSyms)
+          if (object.id()->owner().IsDerivedType()) {
+            if (auto dataRef{ExtractDataRef(object.designator)}) {
----------------
skatrak wrote:

If it's a derived type and `ExtractDataRef` returns `std::nullopt`, then nothing will be done with the created `mapOp`, without letting the user know. Is that the expected behavior? If `ExtractDataRef` is always expected to return something in this case, then maybe we could assert instead. If not, maybe it should error out or at least emit a warning.

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


More information about the llvm-branch-commits mailing list