[flang-commits] [flang] [mlir] [mlir][OpenMP] - MLIR to LLVMIR translation support for delayed privatization of allocatables in `omp.target` ops (PR #113208)
Kareem Ergawy via flang-commits
flang-commits at lists.llvm.org
Thu Oct 24 06:08:30 PDT 2024
================
@@ -3340,6 +3397,48 @@ convertOmpTarget(Operation &opInst, llvm::IRBuilderBase &builder,
bool isOffloadEntry =
isTargetDevice || !ompBuilder->Config.TargetTriples.empty();
+ // For some private variables, the MapsForPrivatizedVariablesPass
+ // creates MapInfoOp instances. Go through the private variables and
+ // the mapped variables so that during codegeneration we are able
+ // to quickly look up the corresponding map variable, if any for each
+ // private variable.
+ if (!targetOp.getPrivateVars().empty() && !targetOp.getMapVars().empty()) {
+ auto argIface = llvm::cast<omp::BlockArgOpenMPOpInterface>(*targetOp);
+ unsigned lastMapBlockArgsIdx =
+ argIface.getMapBlockArgsStart() + argIface.numMapBlockArgs() - 1;
+ OperandRange privateVars = targetOp.getPrivateVars();
+ std::optional<ArrayAttr> privateSyms = targetOp.getPrivateSyms();
+ auto reverseIt = mapVars.rbegin();
+ for (auto [privVar, privSym] :
----------------
ergawy wrote:
I know the following point should have been raised in an earlier PR probably, but I think this algorithms is a bit brittle since it always assumes the last mappings are the ones corresponding the privates vars. Can we instead record that info on the `private` op level? So each `private` op holds an optional MLIR value that corresponds to its map if needed.
https://github.com/llvm/llvm-project/pull/113208
More information about the flang-commits
mailing list