[Mlir-commits] [mlir] [mlir][OpenMP] add attribute for privatization barrier (PR #140089)

Tom Eccles llvmlistbot at llvm.org
Fri May 16 08:04:49 PDT 2025


================
@@ -2872,6 +2872,23 @@ func.func @parallel_op_privatizers(%arg0: !llvm.ptr, %arg1: !llvm.ptr) {
   return
 }
 
+// CHECK-LABEL: parallel_op_privatizers_barrier
+// CHECK-SAME: (%[[ARG0:[^[:space:]]+]]: !llvm.ptr, %[[ARG1:[^[:space:]]+]]: !llvm.ptr)
+func.func @parallel_op_privatizers_barrier(%arg0: !llvm.ptr, %arg1: !llvm.ptr) {
+  // CHECK: omp.parallel private(
+  // CHECK-SAME: @x.privatizer %[[ARG0]] -> %[[ARG0_PRIV:[^[:space:]]+]],
+  // CHECK-SAME: @y.privatizer %[[ARG1]] -> %[[ARG1_PRIV:[^[:space:]]+]] : !llvm.ptr, !llvm.ptr)
+  // CHECK-SAME: private_barrier
----------------
tblah wrote:

There is nowhere in MLIR to print the omp.barrier that accurately describes its location in generated code, otherwise I could have moved the `omp.barrier` operation instead of adding this new attribute.

This barrier is inserted between the copy regions of firstprivate arguments and the initialization call for the openmp construct. If the omp.barrier was placed before the construct this would indicate the barrier came before firstprivate copying. If it was placed inside the nested region it would come after the start of the construct (which I tried but it turns out not to work because some constructs won't run on all active threads e.g. a sections construct with fewer sections than the number of available threads).

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


More information about the Mlir-commits mailing list