================
@@ -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
_______________________________________________
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
