[Openmp-commits] [PATCH] D107316: [OpenMP] Add missing `tt_hidden_helper_task_encountered` along with `tt_found_proxy_tasks`
Shilei Tian via Phabricator via Openmp-commits
openmp-commits at lists.llvm.org
Sun Dec 26 11:17:03 PST 2021
tianshilei1992 added inline comments.
================
Comment at: openmp/runtime/src/kmp_tasking.cpp:3080
if (nthreads == 1 &&
- KMP_ATOMIC_LD_ACQ(¤t_task->td_incomplete_child_tasks))
+ KMP_ATOMIC_LD_ACQ(¤t_task->td_incomplete_child_tasks) > 1)
use_own_tasks = 1;
----------------
That is the reason that we can observe hangs in the past. Basically, D107496 changed the way to track incomplete children. Once we encountered a hidden helper task or detachable task, all following tasks will be tracked. In the simple case we added to this patch, we have a regular target region depending on a hidden helper task. The allocation of the regular target region increments the counter of incomplete children. Since it is a regular target region with dependences, clang lowers it to a function call to `__kmpc_omp_wait_deps` first followed by invoking the task directly. At this moment, `current_task->td_incomplete_child_tasks` is either 2 or 1, depending on whether the hidden helper task is finished, but it will never be 0. Therefore, we are trapped into the infinite loop here.
I simply change it to check if the `td_incomplete_child_tasks` is greater than 1 which can exclude itself. Since we don't know if the function call to `__kmpc_omp_wait_deps` is for `taskwait` or for a `if0` task, I don't have any other good idea on the top of my mind to check here. We might have very tiny performance loss, caused by returning from this function and then entering it again, for the fairly rare case.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D107316/new/
https://reviews.llvm.org/D107316
More information about the Openmp-commits
mailing list