================ @@ -58,21 +67,62 @@ class MapInfoFinalizationPass /*corresponding local alloca=*/fir::AllocaOp> localBoxAllocas; - void genDescriptorMemberMaps(mlir::omp::MapInfoOp op, - fir::FirOpBuilder &builder, - mlir::Operation *target) { - mlir::Location loc = op.getLoc(); - mlir::Value descriptor = op.getVarPtr(); + /// getMemberUserList gathers all users of a particular MapInfoOp that are + /// other MapInfoOp's and places them into the mapMemberUsers list, which + /// records the map that the current argument MapInfoOp "op" is part of + /// alongside the placement of "op" in the recorded users members list. The + /// intent of the generated list is to find all MapInfoOp's that may be + /// considered parents of the passed in "op" and in which it shows up in the + /// member list, alongside collecting the placement information of "op" in its + /// parents member list. + void + getMemberUserList(mlir::omp::MapInfoOp op, + llvm::SmallVectorImpl<ParentAndPlacement> &mapMemberUsers) { ---------------- ergawy wrote:
In what scenario will `mapMemberUsers` end up with more than one element? As a test (just to learn more about the changes), I modified this function as follows and none of the tests failed: ```diff --- a/flang/lib/Optimizer/OpenMP/MapInfoFinalization.cpp +++ b/flang/lib/Optimizer/OpenMP/MapInfoFinalization.cpp @@ -81,8 +81,10 @@ class MapInfoFinalizationPass for (auto *users : op->getUsers()) if (auto map = mlir::dyn_cast_if_present<mlir::omp::MapInfoOp>(users)) for (auto [i, mapMember] : llvm::enumerate(map.getMembers())) - if (mapMember.getDefiningOp() == op) + if (mapMember.getDefiningOp() == op) { mapMemberUsers.push_back({map, i}); + break; + } } llvm::SmallVector<int64_t> ``` Also, `mapMemberUsers[0]` is the only element used below (in `genDescriptorMemberMaps`). https://github.com/llvm/llvm-project/pull/111192 _______________________________________________ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits