[flang-commits] [flang] [llvm] [mlir] [mlir][OpenMP] - MLIR to LLVMIR translation support for delayed privatization of allocatables in `omp.target` ops (PR #116576)
Sergio Afonso via flang-commits
flang-commits at lists.llvm.org
Wed Dec 11 07:43:31 PST 2024
================
@@ -3824,6 +3857,19 @@ convertOmpTarget(Operation &opInst, llvm::IRBuilderBase &builder,
bool isTargetDevice = ompBuilder->Config.isTargetDevice();
auto parentFn = opInst.getParentOfType<LLVM::LLVMFuncOp>();
auto &targetRegion = targetOp.getRegion();
+ // Holds the private vars that have been mapped along with
+ // the block argument that corresponds to the MapInfoOp
+ // corresponding to the private var in question.
+ // So, for instance
+ //
+ // %10 = omp.map.info var_ptr(%6#0 : !fir.ref<!fir.box<!fir.heap<i32>>>, ..)
+ // omp.target map_entries(%10 -> %arg0) private(@box.privatizer %6#0-> %arg1)
+ //
+ // Then, %10 has been created so that the descriptor can be used by the
+ // privatizer
+ // @box.privatizer on the device side. Here we'd record {%6#0, 0} in the
+ // mappedPrivateVars map.
+ llvm::DenseMap<Value, int> mappedPrivateVars;
----------------
skatrak wrote:
My comment was more about the implementation of this map specifically, rather than the design of the operation. `mappedPrivateVars` will only contain indices that point to valid block arguments of the operation, so it should be possible to insert the actual value instead. Then, within `findAssociatedValue()`, you wouldn't have to call `targetOp.getRegion().getArgument()` or even pass `targetOp` at all because it would be done here already.
I'm adding a suggestion block below to illustrate what I mean.
https://github.com/llvm/llvm-project/pull/116576
More information about the flang-commits
mailing list