[Mlir-commits] [mlir] [MLIR][OpenMP] Support basic materialization for `omp.private` ops (PR #81715)

Kareem Ergawy llvmlistbot at llvm.org
Tue Feb 20 21:20:09 PST 2024


================
@@ -1000,6 +1000,26 @@ convertOmpWsLoop(Operation &opInst, llvm::IRBuilderBase &builder,
   return success();
 }
 
+/// Replace the region arguments of the parallel op (which correspond to private
+/// variables) with the actual private varibles they correspond to. This
+/// prepares the parallel op so that it matches what is expected by the
+/// OMPIRBuilder.
+static void prepareOmpParallelForPrivatization(omp::ParallelOp opInst) {
----------------
ergawy wrote:

>  and add some findPrivVars that checks for if(definedInCaller(Blocks, V)) and returns the variables?

I think that will not work. If you check the definition of [definedInCaller](https://github.com/llvm/llvm-project/blob/f740366fa68d3cfceda7efe2d573348253fbb1e9/llvm/lib/Transforms/Utils/CodeExtractor.cpp#L279), you will see that it returns `true` only if a value is defined by an instruction that belongs to a block that is not an element in the `Blocks` argument to the function.

So, if you do not use `findInputsOutputs` and instead directly create a `findPrivVars` that directly calls `if(definedInCaller(Block, V))` without iterating over all instructions in the outlined region as `findInputsOutputs` [does](https://github.com/llvm/llvm-project/blob/f740366fa68d3cfceda7efe2d573348253fbb1e9/llvm/lib/Transforms/Utils/CodeExtractor.cpp#L652), I think you will falsely detect too many values as being private.

Please let me know if I misunderstood your suggestion! :)

Also, what is the disadvantage of the current approach of pre-processing the `omp.parallel` op by remapping the block argument uses to the original SSA values that will be privatized?

https://github.com/llvm/llvm-project/pull/81715


More information about the Mlir-commits mailing list