[Mlir-commits] [mlir] [MLIR][OpenMP] Add OMP Declare Mapper MLIR Op definition (PR #117045)

[Akash Banerjee]

================
@@ -879,6 +879,14 @@ cleanup {
   omp.yield
 }
 
+// CHECK: %[[DECL_VAR:.*]] = llvm.alloca %{{.*}}
+// CHECK: %[[DECL_MAP_INFO:.*]] = omp.map.info var_ptr(%[[DECL_VAR]] : !llvm.ptr, !llvm.struct<"my_type", (i32)>) map_clauses(tofrom) capture(ByRef) -> !llvm.ptr {name = ""}
+// CHECK: omp.declare_mapper @my_mapper : %[[DECL_VAR]] : !llvm.ptr : !llvm.struct<"my_type", (i32)> map_entries(%[[DECL_MAP_INFO]] : !llvm.ptr)
+%decl_c1 = arith.constant 1 : i64
+%decl_var = llvm.alloca %decl_c1 x !llvm.struct<"my_type", (i32)> : (i64) -> !llvm.ptr
+%decl_map_info = omp.map.info var_ptr(%decl_var : !llvm.ptr, !llvm.struct<"my_type", (i32)>) map_clauses(tofrom) capture(ByRef) -> !llvm.ptr {name = ""}
+omp.declare_mapper @my_mapper : %decl_var : !llvm.ptr : !llvm.struct<"my_type", (i32)> map_entries(%decl_map_info : !llvm.ptr)
----------------
TIFitis wrote:

Looking at Clang's implementation and the OMP RTL calls, declare mappers are processed a bit differently than simply "copying" the mapClause info to wherever the declMapper is referenced.

For the sake of keeping the conversation at one place, do you mind continuing this conversation at #117046. We already have an ongoing discussion there on the same topic, where I've tried to explain how declare mapper works and how it's processed.

In short, the declMapper directive results in a new mapperFunc in the code. A ptr to this mapperFunc is then passed on to the RTL call. Generation of this mapperFunc along with passing it to the RTL is handled by the OMPIRBuilder in #110001.

So every declMapperOp eventually gets lowered to it's own function, which is referenced through the target directive map clauses.

I've also discussed the issue with decoupling the map clause from the directive in #117046. AFAIK I don't think we have currently have floating mapInfoOps that are not tied to any Op through the mapClause(mapEntries). If we introduce this "special" case of map clause where it's attached to the parentOp through a nested region, then I think we would end up having to handle this special case elsewhere such as different stages of lowering, map passes(mapInfoFinalization) etc. I don't see what we stand to gain from nesting the single `var` that's associated with the declMapperOp to a region instead of hoisting it. Only problem I can think of is violating the scoping rule, which I think can be enforced through the declMapperOp's verifier.

Let me know if this changes your view, or if you're still in favour of nesting mapInfoOps.

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