[flang] [llvm] [mlir] [mlir][OpenMP] - MLIR to LLVMIR translation support for delayed privatization of allocatables in `omp.target` ops (PR #116576)
Sergio Afonso via llvm-commits
llvm-commits at lists.llvm.org
Wed Dec 11 07:43:32 PST 2024
================
@@ -1290,6 +1286,43 @@ static LogicalResult allocAndInitializeReductionVars(
isByRef, deferredStores);
}
+/// Return the llvm::Value * corresponding to the `privateVar` that
+/// is being privatized. It isn't always as simple as looking up
+/// moduleTranslation with privateVar. For instance, in case of
+/// an allocatable, the descriptor for the allocatable is privatized.
+/// This descriptor is mapped using an MapInfoOp. So, this function
+/// will return a pointer to the llvm::Value corresponding to the
+/// block argument for the mapped descriptor.
+static llvm::Value *
+findAssociatedValue(Value privateVar, llvm::IRBuilderBase &builder,
+ LLVM::ModuleTranslation &moduleTranslation,
+ omp::TargetOp targetOp = nullptr,
+ llvm::DenseMap<Value, int> *mappedPrivateVars = nullptr) {
----------------
skatrak wrote:
Nit: Feel free to ignore if you disagree or if it introduces implementation issues, but since both things are expected to be passed in the same situation, how about wrapping them in an `std::optional` instead of passing pointers?
```suggestion
std::optional<std::pair<omp::TargetOp, llvm::DenseMap<Value, int> &>> targetInfo) {
```
I wouldn't mind introducing a small struct to hold this information in place of the `std::pair` either.
However, if you agree to change `mappedPrivateVars` to `llvm::DenseMap<Value, Value>`, as discussed in another comment in this file, then the suggestion here would be to just pass a pointer to that map. There would be no need to pass `targetOp` in that case. Instead, `blockArg` could just be obtained by querying `(*mappedPrivateVars)[privateVar]`.
https://github.com/llvm/llvm-project/pull/116576
More information about the llvm-commits
mailing list