================
@@ -8222,6 +8226,61 @@ convertOmpTarget(Operation &opInst, llvm::IRBuilderBase
&builder,
bool isOffloadEntry =
isTargetDevice || !ompBuilder->Config.TargetTriples.empty();
+ // Validate and resolve in_reduction clauses on omp.target. We currently
+ // only support the non-offload host-fallback path: the per-task private
+ // pointer is obtained by calling __kmpc_task_reduction_get_th_data inside
+ // the to-be-outlined target task body. Threading that pointer through the
+ // device kernel argument list is left as follow-up work.
+ SmallVector<llvm::Value *> inRedOrigPtrs;
+ if (!targetOp.getInReductionVars().empty()) {
+ if (isTargetDevice || isOffloadEntry)
----------------
skatrak wrote:
Let me know if I'm misunderstanding, but it doesn't seem like device
compilation would need to do anything about `in_reduction` variables, as
they're just supposed to behave as a `map(tofrom)` variable from the target
device perspective. It's only the host that needs to make sure the reduction is
properly carried out using the value mapped back from the target device.
At this specific point, that would mean only checking `if
(!ompBuilder->Config.TargetTriples.empty())`.
As a more general comment, I'm not quite sure about the need for `in_reduction`
to define entry block arguments for `omp.target`. The reduction variable itself
must be mapped, and only the returned value will be used for the reduction, so
why not represent it like this?
```mlir
%x = ... : !llvm.ptr
%m = omp.map.info var_ptr(%x : !llvm.ptr, i32) map_clauses(tofrom)
capture(ByRef) -> !llvm.ptr
omp.target in_reduction(@add_i32 %x : !llvm.ptr) map_entries(%m -> %prv :
!llvm.ptr) {
...
llvm.store %..., %prv : i32, !llvm.ptr
omp.terminator
}
```
That way we can handle the target region on the device normally and only do
extra handling on the host so that we e.g. map a copy of the `in_reduction`
variable and then combine it with the shared one after the target task ends.
https://github.com/llvm/llvm-project/pull/199967
_______________________________________________
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
