skatrak wrote: > would you prefer target in_reduction to avoid a separate in_reduction block > argument and instead use the map_entries block argument for the target body, > with the reduction-private handling done only on the host side?
Well, I'm not entirely sure about which option would be the best in advance. However, I can see that it would make lowering of the target region trivial, as it can just ignore the `in_reduction`. It also makes more sense in that the `in_reduction` happens outside of the task-generating construct itself and the other approach causes accesses to the variable to not refer to the mapped value. The only concern I have is about how much of a problem it would be for the host side to map a copy of the actual `in_reduction` variable to avoid race conditions when mapping it back, rather than using the original variable directly, and how much of a problem it would be to identify a mapped value that is also `in_reduction` and thus needs special handling. So, I think this is worth exploring. It might even end up being something that makes sense to do for `in_reduction` outside of `target`, though I'm even less sure about that. Perhaps you can add it as a separate commit so you can roll it back if the tradeoff doesn't pay off in the end. Or just give it a try and make a comment here if there are fundamental problems that come up. 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
