[Openmp-commits] [PATCH] D64080: [OPENMP]Make __kmpc_push_tripcount thread safe.

Hal Finkel via Phabricator via Openmp-commits openmp-commits at lists.llvm.org
Tue Jul 2 21:23:38 PDT 2019

hfinkel added a comment.

In D64080#1567632 <https://reviews.llvm.org/D64080#1567632>, @ABataev wrote:

> In D64080#1567533 <https://reviews.llvm.org/D64080#1567533>, @hfinkel wrote:
> > In D64080#1567348 <https://reviews.llvm.org/D64080#1567348>, @ABataev wrote:
> >
> > > In D64080#1567327 <https://reviews.llvm.org/D64080#1567327>, @grokos wrote:
> > >
> > > > A long time ago we had identified the problem with the loop trip count and if I recall correctly the proposed solution was to store the trip count per OpenMP task. The fix would be implemented in libomp because libomptarget has no notion of tasks.
> > > >
> > > > @AlexEichenberger Can you confirm whether or not this is the case? I may confuse this with something else...
> > >
> > >
> > > The patch does exactly what you said: stores tripcount per task, but in the libomptarget, not libomp. When it will be implemented in libomp, we could remove this code. But we need fully functional implementation now, not in the future.
> >
> >
> > If this should really be fixed in libomp, then we should fix it there. At the very least, there should be a FIXME about removing the workaround once the libomp fix is in place. @AndreyChurbanov, any thoughts on this?
> Hal, currently target tripcount has nothing to do with libomp. It is stored as part of the device in libomptarget. So, I think, to fix this problem in libomptarget is fine.
>  To put it into target task allocated memory is completely different problem, which requires some redesign and full support of target tasks.

I think that it makes sense to note this in the code. Can you please add a comment along the lines of (assuming that I'm understanding you correctly):

  // NOTE: Once libomp gains full target-task support, this state should be moved into the target task in libomp.

> Plus, just like I said, it is not true that libomptarget is thread agnostic. Actually, it is not, since it uses `__kmpc_omp_taskwait(NULL, 0)` for dependendent target regions. Moreover, it is not thread safe too, because uses not real thread ID,  but hardcoded `0` thread ID. It may lead to problems even in a single-threaded environment if the caller thread is not a master thread.

This is the issue to which "I'm going to fix this in the next patch." refers, correct?

  rOMP OpenMP



More information about the Openmp-commits mailing list