[llvm-branch-commits] [Flang][OpenMP][MLIR] Extend derived (record) type map support in Flang OpenMP by adding some initial support for explicit member mapping (PR #81511)

[via llvm-branch-commits]

================
@@ -1859,7 +1983,13 @@ bool ClauseProcessor::processMap(
     llvm::SmallVectorImpl<const Fortran::semantics::Symbol *> *mapSymbols)
     const {
   fir::FirOpBuilder &firOpBuilder = converter.getFirOpBuilder();
-  return findRepeatableClause<ClauseTy::Map>(
+
+  llvm::SmallVector<mlir::Value> memberMaps;
+  llvm::SmallVector<mlir::Attribute> memberPlacementIndices;
+  llvm::SmallVector<const Fortran::semantics::Symbol *> memberParentSyms,
+      mapSyms;
----------------
agozillon wrote:

We do currently I think (but perhaps my thinking is not perfect on this and I am wrong), this function optionally takes in a list of mapSymbols that we populate, which is only currently provided and needed by Target and Target Data I believe. However, for the member mapping we unfortunately need (at least with the current way of doing it, I am always open to suggestions) to keep track of the set of symbols all the time. It may be that it's just better to always take the symbol set in, even if we don't use it, not sure how feasible that is though, but if we're populating the list always then I suppose it's not a lot of extra overhead if the caller discards it. But in essence mapSyms is there to be an always populated list of symbols so we can use it to keep track of the symbols used for tracking mapped parents. And I think optionally checking if it is null or not and then using either mapSyms or mapSymbols is perhaps just adding more noise than optionally assigning at the end, but I am open to either, and also checking if we can always pass the mapSymbols in regardless of directive.

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