================
@@ -1783,6 +1783,98 @@ void collectMapDataFromMapOperands(MapInfoData &mapData,
}
}
+static int getMapDataMemberIdx(MapInfoData &mapData,
+ mlir::omp::MapInfoOp memberOp) {
+ int memberDataIdx = -1;
+ for (size_t i = 0; i < mapData.MapClause.size(); ++i) {
+ if (mapData.MapClause[i] == memberOp)
+ memberDataIdx = i;
+ }
+ return memberDataIdx;
+}
+
+static mlir::omp::MapInfoOp
+getFirstOrLastMappedMemberPtr(mlir::omp::MapInfoOp mapInfo, bool first) {
+ // Only 1 member has been mapped, we can return it.
+ if (mapInfo.getMembersIndex()->size() == 1)
+ if (auto mapOp = mlir::dyn_cast<mlir::omp::MapInfoOp>(
+ mapInfo.getMembers()[0].getDefiningOp()))
+ return mapOp;
+
+ int64_t curPos =
+ mapInfo.getMembersIndex()->begin()->cast<mlir::IntegerAttr>().getInt();
+
+ int64_t idx = 1, curIdx = 0, memberPlacement = 0;
+ for (const auto *iter = std::next(mapInfo.getMembersIndex()->begin());
+ iter != mapInfo.getMembersIndex()->end(); iter++) {
+ memberPlacement = iter->cast<mlir::IntegerAttr>().getInt();
+ if (first) {
+ if (memberPlacement < curPos) {
+ curIdx = idx;
+ curPos = memberPlacement;
+ }
+ } else {
+ if (memberPlacement > curPos) {
+ curIdx = idx;
+ curPos = memberPlacement;
+ }
+ }
+ idx++;
+ }
+
+ if (auto mapOp = mlir::dyn_cast<mlir::omp::MapInfoOp>(
+ mapInfo.getMembers()[curIdx].getDefiningOp()))
+ return mapOp;
+
+ return {};
+}
+
+std::vector<llvm::Value *>
+calculateBoundsOffset(LLVM::ModuleTranslation &moduleTranslation,
----------------
agozillon wrote:
Done, hopefully the comments are a little helpful!
>From my (possibly flawed, as I may be attributing the need for this to the
>wrong thing, so if someone wishes to correct me please do) understanding the
>backwards iteration is required to create the appropriate array offsetting in
>Fortran due to Fortran's column-major layout ordering (the bounds are still
>provided in row-major order I believe, the same as it's written in Fortran I
>think). If this is indeed the case then it does mean we're currently making a
>bit of an exception for Fortran here, and to keep this lowering and dialect
>language agnostic whenever we get a C/C++ frontend we will likely have to
>agree on a bounds ordering, and one of the languages may have to do a
>re-ordering in their frontend.
https://github.com/llvm/llvm-project/pull/81510
_______________________________________________
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
